 |
I have done a simply test with one only video (1920x1080) in one only video track (and Proxy scale 1/3 without Scaler, enabled). No Mixer/Multicamera View, no audio. I am using the last Cinelerra-GG_20190430 version and the old Cinelerra-GG_20181231 version. - Screencast "Timeline_1and4_keys_(cin-20190430).ogv" (at 25fps) to: https://streamable.com/vo80d - Screencast "Timeline_1and4_keys_(cin-20181231).ogv" (at 25fps) to: https://streamable.com/tsnq8 The screencasts shows I press and hold down the 1 key (and then also the 4 key). In Terminal the top command shows that in the Cin20190430 version the %cpu is 8 max, while in the Cin20181231 version the %cpu is 18 max. I don't know if this new information about different cpu consumes may says to you more. My Notebook is very old so it is more in evidence the Pierre's issue. I don't know if it can help to narrow the issue. Thanks. |
|
|
@Phyllis On my old Notebook, with the last Cin-gg 20190420 version, the hairline (the cursor on timeline) doesn't move with "1" and "4" key, and the timecode jump. With the Cin-GG_20181231 version, the hairline moves, forward ("1") and backward ("4"), almost smooth and slowly (always Proxy is enabled without Scaler). I understand that it can not help you. I am sorry. @Pierre If you want to test with the old Cin-GG_20181231 version I had archived the Ubuntu16 and Mint18.2 compressed files. Consider to Backup your project file before. Thanks. https://www.dropbox.com/s/6oimd59wnhee5ar/cinelerra-5.1-mint18.2-20181231.x86_64-static.txz?dl=0 |
 |
Sorry IgorBeg, I can't test the old version 20181224 for LinuxMint, I don't have it anymore and it doesn't seem to be available on the website. |
 |
IgorB: I too have been testing with the 20181224 version and that does seem to be a little bit better, but I did not think it was significantly better. But I have been unable to find the cause and GG thinks it is just short on CPU power for me. In note 1396, we did mention that there is a definite error in reverse that has not been fixed yet but will get done before the builds at the end of the month (maybe earlier, I hope). |
|
|
Thanks Pierre for all your info. (You have a powerful workstation). Excuse me, Pierre, for all these questions but I am wrong. I just tested "4" and "1" keys in Compositor and in Main window, like you wrote in issue's description except for Multicamera/Multiviewer. For the tests I used "WhatTimeIsIt" project; below the link at the compressed file: https://www.dropbox.com/s/o9i44fnszrt6wjq/WhatTimeIsIt.tar.gz?dl=0 I tested with Cin-GG_version_20181231 and with Cin-GG_version_20190420, in the same condition: load the "WhatTimeIsIt" project and I enable Proxy: without Scaler, Scale=1/4, mov.mov, bitrate=1800000. It works better (but not smooth, due at my poor system) with the old version Cin-GG_version_20181231. In the last version happens what you have written. Then, I think, it doesn't depend from the codec or Multiviewer. I don't know if it may help the developers (GG&Phyllis), but if you could test with the old Cin-GG_20181231 version to see the different behaviour. Sorry if I am wasting your time. |
|
|
No problems for the information, there are no state secrets here. Indeed, I chose Proxy with Scaler to avoid problems with some plugins like Title. I think my CPU and GPU should be powerful enough to support this. The bit rate of my proxy (mpeg.mpeg) is: 2000000 Quality: -1 Mediainfos says that Proxy has GOP of: N12 My system and software are on an SSD The media are on an internal raid-0 (software) composed of two drives (sata-III) WD Black 7200 I also have other internal disks for rendering and saving the Raid-0 (in addition to other external backups, including one on a NAS. |
|
|
Thanks Pierre for your info. Mmh, it is strange. As you know, GOP=1 means that your videos have all i-frames (like a sequence of all png files) and that is very good for editing. More, I see in your Issue's Detail that you have a powerful computer with a lot of RAM. If you can use Proxy without Scaler I think your computer may works better but, probably, you can not for your reasons (like to use Title effect, I think). PS: For complete info, in proxy, what is the bitrate you use in mpeg container? Are your media in a SSD or SATA disk? External or internal? If External, which protocol: USB2, USB3, e-SATA, Thunderbolt? (if you don't want to answer these questions for privacy I understand) |
|
|
I have Mediainfo but in the case of my DNxHD files, there was no mention of GOP. Result of "getgop.sh" script by Dan Dennedy: GOP: M=0, N=1 (this line appears very numerous times) Max. GOP = 1 My scale factor for proxy is 1/2 in mpeg. (so the image does not lose too much of its accuracy while using much smaller files. Approximately 1 to 2% of the original file). |
|
|
Hi Pierre (sorry, I greet you very little), About GOP, I wrote at https://lists.cinelerra-gg.org/pipermail/cin/2019-February/000254.html if you have time to read. If you have Mediainfo installed, it says to you the video's info, with GOP value of your video. If you haven't Mediainfo installed, like me, you can use "getgop.sh" script by Dan Dennedy. I added a compressed file. Inside, you find the script and my "readme" for the info. Keep in mind I am really ignorant in OS-Linux (and not only). About proxy with Scaler. The frames are converted at the new, smaller, resolution (I don't know your scale factor) and then rescaled again to 1920x1080. Then the decoding is less hard but not too much, I think; and long-GOP doesn't help. getgop_byDanDennedy.tar.gz (1,046 bytes) |
|
|
Hi IgorBeg, Where can I find information on the GOP of my files? I use with Scaler for proxy. |
|
|
Pierre, sorry if I am writing here. Could you tell me (us) the GOP value of yours media, please? Maybe your media use long-GOP and then Cinelerra-GG (like all others NLE) have to decode a lot of data, multiply per the number of the Multiviewers. I read you are also using proxy: with or without Scaler? Thanks. |
|
|
Yes, but go ahead and email the xml file also. |
|
|
I thought you wanted to have a section of the editing with the xml file and the portions of the associated source files. But if I understand your procedure correctly, all you will get is the beginning of the first file of each of the 4 cameras. Is that what you want? |
|
|
On any window after the prompt of: pierre@i7-3770k is where you type those lines. if= means the input file and of= is the name of the output file which would be the file to send. Meanwhile I downloaded 4 dnxhd files and opened mixers but they are not all that large. GG found 1 error where it definitely goes the wrong direction for 1 frame when change from using the key "1" to using the key "4". He will take a look at fixing this so this is a good find. Also, I showed him where I hold down the 1 key or the 4 key continuously and when you watch the timeline, you see the timeline really jerking for a bit. He says this means that the commands of the 1 or 4 key are occurring faster than the computer can process. If you run the "top" command (after the pierre@i7-3770k prompt), at least on my laptop, the CPU usage is maxed out at 1400% -- and it just can not go any faster so the timeline is jerky. I am doing more testing with the dnxhd files that I have now. |
|
|
Where should I put these lines? At what time? I need a procedure. |
|
|
To send a short "slice" do this for each of the 4 files, substituting camera# with the actual name of the input file: dd if=camera1.dnxhd of=/tmp/camera1.slice bs=1M count=60 dd if=camera2.dnxhd of=/tmp/camera2.slice bs=1M count=60 dd if=camera3.dnxhd of=/tmp/camera3.slice bs=1M count=60 dd if=camera4.dnxhd of=/tmp/camera4.slice bs=1M count=60 You can change the count to a smaller number than 60 (which is about 60 MB) if too much for sending. Meanwhile I will try to find some very large DNxHD files to download and test. |
|
|
The new version does not solve anything. The problem is non-existent in the Viewer, but it is present in the composer and especially very visible in the Mixers, particularly in reverse scrolling by the "4" key. If I keep the "4" button pressed for several seconds, it is certain that the image will scroll in a very jerky way.... I'm ready to send you a short "slice" of my timeline where the problem is very visible... but is there a way to send you only the part of the 4 source files corresponding to this short "slice"? Otherwise, my source files are very, very large (DNxHD)... one of the cameras lasts 34 minutes (57 GB) and the others, although shorter, are still large too. I tried to replace X11 with OpenGL, but as soon as I try to open the project containing the 4 mixers, Cinelerra-GG crashes. |
|
|
A new Mint18 version is at: https://cinelerra-gg.org/download/testing/cinelerra-5.1-mint18-x86_64-static.txz But after testing here with gg, the results are that it appears to be working well enough. When we use X11, we play and get 30fps. When we use the single frame 1 and 4 keys, it will not be as smooth with 4 mixers as it would with just one camera because it has to run the render 4 times more as it runs for each camera. Surprisingly when we use OpenGL instead of X11 and just play every frame, the fps varies from 30 to 23 to 10. There may be a good explanation for "regularly after a number x (5, 10, 20...) of frames in the right direction, the scrolling reverses for a moment in the opposite direction." This may be due to ffmpeg seek position in relation to cache - as the code is executed it checks the current position with where it is supposed to be going and repositions accordingly. I have seen this myself recently but can not remember how I produced this so that I could show gg. It may be that I saw the problem before some of the recent changes he checked in which would not have been in the March 31 Mint18 build. This is not a definitive answer as there may really be a problem but would need to have a specific camera output that creates this anomaly. If you want to send a short section of media privately where you definitely see this problem, gg will be able to take a closer look to confirm this behavior or find a different problem. However if you still see the problem on this latest Mint 18 build, 1 suggestion gg had was to change Settings->Preferences, Interface tab, Cache MB to 1 (before changing this, check to see what you currently have it set to). |
|
|
OK, gg was wondering if that is what you really meant. |
|
|
To avoid confusion, I corrected the summary and description of this bug; I replaced the term used multi-screen by Multi-Camera / Mixer. |
|
|
Sorry I misspoke, I wrote multi-screens... but I should have written multi-cameras (mixers) in my case 4 mixers of 4 cameras. I don't think this problem is necessarily related to my three computer monitors. |
|
|
I will have to hookup another monitor to my laptop and test this more carefully (probably not until Saturday though). There was a fix added in the last week or so for the single frame keys which, of course, you do not have. If I can not generate a problem this weekend, gg will make a Mint 18 test version for you to test instead. |
- Anonymous
