 |
MatN: "I was running some tests on what would be the better default," Good to know and have you verify that this is a better choice". " original default (ffmpeg.mp4, 16mmto264.mp4) produces proxies which were much bigger than the original." The usual reason for producing larger size output is the bitrate parameter (check the wrench values). "Some of the proxy creations don't use 100% CPU". This may actually be a good thing - my laptop has about 4 cpus and on a really small test runs at least 8 times faster than gg's 128 cpus -- that is because it stupidly splits up this small test into about 120+ pieces and spends so much of its time doing so. "It's amazing how many improvements you two get into the product in one month." This has purposely been an over the top month because of the new website and trying to get to the "tipping point" where a couple of glaring missing pieces have had to be added -- in particular the copy/paste/group behavior. Unfortunately, it has been a little painful for some of the core users who besides testing actually use it to produce good results. Please continue to pass along any observations as they are quite helpful and useful. |
 |
Ah, you beat me to it. I was running some tests on what would be the better default, but I'm quite happy with your suggested new defaults. You can close this issue as far as I am concerned, the original issue is gone. A few remarks, not sure if these should be issues: - The original default (ffmpeg.mp4, 16mmto264.mp4) produces proxies which were much bigger than the original. There must be something wrong here or in the code. I'll do some more checks. - Some of the proxy creations don't use 100% CPU. It could be that they leave on purpose one of the cores unused. It's amazing how many improvements you two get into the product in one month. |
|
|
I did do some timings this morning and found "mpeg" to be almost twice as fast as "webm" for small tests and saw that that is what IgorBeghetto uses so gg is going to check in this as default in the next couple of days. And I changed Features. Another improvement is now out there. |
|
|
Your effort to "get to the bottom of this" is going to save new users from being discouraged and giving up when they encounter the same problem. A fix is in and you are correct that this problem is due to a having no previous setting in $HOME/.bcast5/ - Cinelerra_rc for the variable PROXY_VIDEO_CODEC. The fix is to have the initial setting in Proxy be ffmpeg, mp4, h265.mp4. Other responses follow: - If it is an informative message, why is the title of the pop-up window "Cinelerra: errors" . I would expect an informative message not stopping the actual function to work. BAD CHOICE OF WORDS, IT IS AN ERROR AND NOT JUST INFORMATIVE. - If indeed the codec fails because of something in the file, why doe it not display any messages when started from within a terminal? I DO NOT HAVE A GOOD ANSWER; I ASSUME BECAUSE THE PROGRAM CODE FIELDS IT. - If ffmpeg/webm is faster for proxy than ffmpeg/mp4, should this not be covered in the manual? As it is, there is no discussion of what format is best to use for scaling. I ADDED THIS SUGGESTION FOR USING WEBM IN FEATURES MANUAL LOCALLY. If you have the chance to test and it is resolved to our satisfaction, let me know so we can claim this long time outstanding bug is actually fixed now. Also, be aware that issue 0000007 and issue 0000058 features will be in the GIT repository. Thanks for your help! and keep digging for more bugs hiding out there. |
|
|
Thanks for the exact steps! your persistence has paid off and I did create the problem. Now I will show GoodGuy and he can hopefully guard against this. |
|
|
I found a way of forcing issue 48 to show up, using the following procedure. Test file: HD video created by Adobe, (445 MByte, H264 1920x1080x50p yuv420), newly installed Mint 19.1 and Cinelerra-gg. 1. Remove .bcast5 directory, delete any proxies remaining. Start Cin5. 2. Load HD file, check project settings match file. alt-r, ffmpeg.mp4, 16mmto264.mp4 (these are the defaults after installing Cin-gg): popup error window as in issue 48. 3. Exit Cin5 (not saving edits), save .bcast5 directory under a different name, delete the original .bcast5 directory. Start Cin5 4. Load HD file, , check project settings match file. alr-r, 1/4, ffmpeg.webm, webm.webm: OK. 5. Exit Cin5 (not saving edits), delete proxies. Start Cin5, Settings->Preferences->Interface: delete existing indexes. 6. Load HD file, check project settings match file. alt-r, ffmpeg.mp4, 16mmto264.mp4: OK 7. Exit Cin5 (not saving edits), delete proxies, delete .bcast5 directory. Start Cin5. 8. Load HD file, check project settings match file. alt-r, ffmpeg.mp4, 16mmto264.mp4: popup error window as in issue 48. So, if the .bcast5 directory is not there, Cin5 creates it on startup, and there is some setting (missing?) in there that causes this issue. Once you made a proxy using another format, it is OK. I hope this helps. |
|
|
Thanks Igor, that works for me. But I wanted find the cause of the original error window. After I got a proxy once, it kept working, although with various results. I just managed to re-create it by using a fresh Mint install and fresh Cin5 install. The defaults then with alt-r are ffmpeg.mp4, and compression 16mmtoh264. This fails with the error popup. I saved the .bcast5 directory, restarted Cin5, used alt-r with ffmpeg.webm, and compression webm.webm. This goes OK. Now in checking if the default settings still fail, I think I found another bug. I´ll report it tomorrow, no more time today. |
 |
MatN, usually my Proxy Settings for 720p (and 1080p) is: /* ********************** */ Scale factor: 1/4 (no Scaler) File Format: FFMPEG - mpeg Video: Compression: mpeg.mpeg Bitrate: 1800000 Quality: -1 Pixels: yuv420p /* ********************** */ |
|
|
I got a partial success now, the video compression settings appear to make the difference. Did some more structured testing, see below. The strange thing is that after I managed to get a first proxy, things started to behave much better. Could there have been a setting in .bcast5 that influenced it? Below are the test platform/procedures/results. ============================================= Testing various proxy options, using the following procedure and indicators of success: - Platform: Mint 18.3, AMD Ryzen 3 2200G, 16G RAM non-ECC, video driver ati, GLX renderer AMD RAVEN, GLX version: 3.0 Mesa 18.0.5, clinfo: no platforms, vainfo: version 0.39.0, no driver name found. - No application is running other than cinelerra-gg 201811, the Thunar file manager, a terminal window, and Xed text editor. None are touched while proxy creation is in progress. - If needed, exit Cin5 without saving edits, unless otherwise indicated. - Delete any proxy files that might still be there, unless otherwise indicated. - Start Cin5 anew, load the video to test proxy procedure on. Check the project settings match the video. - Set proxy settings, and start (click green V in lower left of proxy window). - No error pop-up window. - Blue progress bar in lower right of Cinelerra progresses. - CPU load is more than 0% (value when in rest) as indicated by XFCE's panel "CPU Graph" plugin which shows all cores, and should go to 0 at the end. - Proxy file appears both in file system and Cinelerra's proxy resources. - Check if any error log appears in /tmp as shown by "ls -alrt /tmp" For each test, the first 3 values are: scale from original, file format, compression settings. Test 1 using using short .avi video from older compact camera (143MByte, mjpeg, 640x480x30p, yuv 4:2:2): 1.1 1/4, ffmpeg.webm, webm.webm : OK (Yes! First time I got a proxy!) 1.2 1/4, ffmpeg.webm, vp8.webm : OK 1.3 1/4, ffmpeg.webm, pass1of2_vp9.webm : nothing happens. 1.4 repeat test 1.2, OK again 1.5 repeat test 1.3, now it works??? and timeline video and compositor blank. Leave the proxy for pass 2, don't restart Cin5. 1.6 1/4, ffmpeg.webm, pass2of2_vp9.webm : nothing happens, proxy date/time not changed. Delete the proxy of pass 1, don't restart Cin5. 1.7 1/4, ffmpeg.webm, pass2of2_vp9.webm : OK. 1.8 repeat test 1.3, OK, results like for test 1.3 . Leave proxy in place, don't restart Cin5 . 1.9 repeat test 1.6, nothing happens results like for test 1.6 . 1.10 repeat test 1.7, results OK. Note: when deleting a proxy file in 1.9, the resources proxy window was not changed until 1.10 finished. Test 2 using using larger .MXF raw video from Sony F55 (734 MByte, H264 3840x2160x25p yuv420): 2.1 1/4, ffmpeg.webm, webm.webm : OK (rendering time 1:54, result 2.2 MByte) 2.2 1/4, ffmpeg.webm, vp8.webm : OK (rendering time 1:16, result 1.5 MByte) 2.3 1/4, ffmpeg.webm, pass1of2_vp9.webm OK (rendering time 0:39, result 555 byte file) and a (updated?) binary log file in /tmp. Delete proxy, don't restart Cin5. 2.4 1/4, ffmpeg.webm, pass2of2_vp9.webm OK (rendering time 0:48, result 1.5 MByte). Log file in /tmp appears not changed (timestamp). ============================================= Note 1: Could it be that if the desired proxy size is too small for some proxy codec/settings? Note 2: It appears Cin determines by file name if a new proxy needs to be made. Is it possible to look at compression settings as well If they are stored in there). |
|
|
Test file worked OK for me either in try ffmpeg first or last with proxy 1/4. I uploaded a file to shows how it worked for me. Something is definitely different in what we are doing. GG just came by and said in the Proxy menu, to check the "wrench" settings and use the default as that works. It is very easy to change settings in here that do not work. Or test like this from a terminal window so that the settings are automatically default: #cd to cinelerra bin path and use a temporary bcast5 file # CIN_CONFIG=/tmp/bcast5 ./ci |
|
|
Yes, please send the file so gg can look at it. Since it is small, you can send to my email account if you want that way no one else sees it. He says that the divide down, going to 1/4, may be the problem because some codecs do not like macroblocks (I think I quoted him correctly). Most interesting though is that it works with "use scalar" which, btw, frequently has different options for the division. Once I test the file, I will note what the errors are and see if they can be made more explicit. The only reason the manual does not suggest webm as faster is because I do not have any concrete numerical statistics, but I will try to validate that and update the manual as that would be helpful. It may be a few days before gg can look at the file as the clip moving, inserting, deleting is pretty involved code that he is working on right now. |
|
|
I have done some more tests, and so far, the error is persistent. If I change the proxy file format to ffmpeg4/webm it fails in the same way. In the "proxy settings" window, I have not changed anything apart from size and file format. I have a small (143M) 640x480x30 AVI file which also exhibits the error. Because I own the copyright on it and it shows no persons in it, I can send it to you via wetransfer, then you can pull it down, let me know. Some remarks though: - If it is an informative message, why is the title of the pop-up window "Cinelerra: errors" . I would expect an informative message not stopping the actual function to work. - If indeed the codec fails because of something in the file, why doe it not display any messages when started from within a terminal? It normally does, I get this with movies shot by at least 2 compact camera's. - If ffmpeg/webm is faster for proxy than ffmpeg/mp4, should this not be covered in the manual? As it is, there is no discussion of what format is best to use for scaling. - On the AVI file, when loading, the terminal window shows some errors. On the HD and UHD files not, yet all fail with the same error message. - I just discovered that if I enable "Use scaler" the error does not appear. This might give a clue as to why it fails. It least it is a workaround. |
|
|
"Error making proxy" is an informative message, not an error in cinelerra. When you proxy a file, it is rendered in the chosen format which in this case is ffmpeg/mp4. If the codec used does not recognize some format/sample rate/frame rate or other parameter value it sends back an error to cinelerra and that is what you see. Switch from mp4 to webm - which is really fast - and see if that works since it does not matter what is used for a proxy. If you want to know why it will not render, send a small sample file that exhibits the problem and we can look at it to see. Will close issue if no new information provided. |
- Anonymous
