May 2019 - Cin - Cinelerra-GG Mailing Lists

When changing colors, the titles disappear
by preobraz＠gmail.com 29 May '19

29 May '19

Hi! When changing colors, the captions of Cinelerra version of April 30 disappear. Please see screencast: https://www.datafilehost.com/d/c5ab7baa -- Ugin.

3 2

French translation update
by Olivier Humbert 29 May '19

29 May '19

Hi people and everyone. Please, find attached an update for the French translation of Cin. It is based on the cin_5.1.20190430-src.tgz version. This updates contains : - translates most of the new translations - fixes most of the "fuzzy" translations - a few improvements/fixes/corrections I would be glad if this update could get in for the next monthly release (to happen in few following days I guess), and then after that, I could start to do a whole review of the French translation (which is in need of that). ------ Note that to do this (attached) translation, I did those steps: 1. extracted the tarball 2. edited po/xlat.sh and added "--from-code utf-8" to the xgettext line (see [1] below) 3. ran: po/xlat.sh > po/cin.po (my understanding is that this command updated the general "cin.po" catalog) 4. ran: msgmerge -U po/fr.po po/cin.po (my understanding is that this command updated the French "fr.po" translation file from the general "cin.po" catalog) 5. translates the po/fr.po It would be great if the knowledgeable people (ping the usual suspects here: Phyllis & GG!) could tell me if this workflow is fine. I hope that helps. Cheers, Olivier [1] without this edit, the step n°3 was throwing an error at me. It might be useful to add this change in the source I guess. -- Site web : https://librazik.tuxfamily.org/ Donation : https://liberapay.com/LibraZiK/ Diaspora : https://framasphere.org/people/8c184af0c9450134f6682a0000053625 Mastodon : https://mastodon.xyz/@LibraZiK

2 6

Solus is working on adding Cinelerra -- email being resent
by Phyllis Smith 29 May '19

29 May '19

This is important email that did not get into the mailing list -- I got carried away and was not paying full attention as usual. The summary. "John" (Jacek Jagosz) has been diligently working on included Cinelerra-GG with Solus. ------------------------------------------------------------------------ Hi, My Cinelerra-GG Solus package is almost ready, but there is a blocker. Video effects that use vaapi don't work and in terminal I get: PluginFVClient::process_buffer() F_denoise_vaapi err: Operacja niedozwolona (that means "operation not allowed" in english). And no matter how long I tried I can't find the root cause. I included FFmpeg, vdpau, libva, libdrm, libva-vdpau-driver and libva-intel-driver. I looked through builds for other systems like from AUR, Fedora or Debian and I don't miss a single dependency. Any help would be appreciated. Second is just a suggestion. If you do make install -j# (# means number of cores) build will fail. Which is a problem, as macro %make_install used in Solus packaging does make install -j#. It'd be nice if Cinelerra used a more standart syntax or at least ignored that argumant instead of failing. And on a last note I still can't join Cinelerra's mailing list. I want to follow the development and know if there is any major bug before I update Cin in Solus' repos. Maybe my mail (@outlook.com) is a problem. I'd be extremely grateful for any help. Jacek Jagosz ------------------------------------------------------------------------ Several Responses from Phyllis: "My Cinelerra-GG Solus package is almost ready, but there is a blocker. Video effects that use vaapi don't work and in terminal I get: PluginFVClient::process_buffer() F_denoise_vaapi err: Operacja niedozwolona (that means "operation not allowed" in english)." I will test this on Intel/Broadwell graphics to make sure I can duplicate the problem and if I can, then gg can diagnose it. This being a blocker with no workaround WILL GET PRIORITY -- the other 2 problems below can be temporarily worked around. "Second is just a suggestion. If you do make install -j# (# means number of cores) build will fail. Which is a problem, as macro %make_install used in Solus packaging does make install -j#. It'd be nice if Cinelerra used a more standart syntax or at least ignored that argumant instead of failing." Will have to also get GG to look at this (unfortunately he is "snowed under" right now and I do not mean the white stuff! I always use the following after doing a build and have no problems with -j# on a Fedora system: CFLAGS=-ggdb make -j28 rebuild_all "And on a last note I still can't join Cinelerra's mailing list. I want to follow the development and know if there is any major bug before I update Cin in Solus' repos. Maybe my mail (@outlook.com) is a problem." I did look at the problem with email joining but only came to the conclusion that it must be Outlook. I know that the mailing list for CV had problems with Yahoo or Hotmail due to restrictive policies causing messages to not arrive, but I do not think that that is the case here. ------------------------------------------------------- WOW, you found something we never would have caught! But there is an easy fix for the blocker that is consistent. A file in {your cinelerra_path}/ffmpeg/plugins.opts contains the currently being used in Cinelerra FFmpeg 371 filters/effects. You will notice that 158 of them are commented out because they do not work with Cin for multiple reasons -- one of which is "Operation not permitted". I will have gg checkin a revised plugin.opts with F_denoise_vaapi commented out so the blocker is gone. Obviously you can test this yourself BUT be sure to delete $HOME/.bcast5/Cinelerra_plugins first so that when you next startup Cinelerra, it will reload the plugins (else it uses the old set). I will still have to test the other 4 to see if they will work F_sharpness_vaapi, F_scale_vaapi, and so on. Also, my big concern is that what happens if you enable vaapi, load these 4 plugins so they stay, and then turn off vaapi for the next run but your session still uses this set of plugins. Should be interesting! BTW - we mostly use Nvidia boards so never would have found this without your help -- thanks. Phyllis/gg -------------------------------------------------------------------------------------------------------------------------- I forgot to technically explain as best as I can convey from GG. FFmpeg uses "filter graphs" but Cinelerra uses a "plugin stack" instead. That is why about 178 of the FFmpeg plugins will not work in Cinelerra. We are sorry that you had to spend so much time trying to determine the problem with F_denoise_vaapi, but in the end you saved other people a lot of time and this was initially very time-consuming/difficult for gg to figure out and workaround in the first place. Phyllis/GG ------------------------------------------------------------------------------------------------------------------------- Unfortunately none of the 5 vaapi ffmpeg plugins will work when you actually try to load them on the timeline so I will be commenting all 5 out. If I counted right, there are still 200 that do work -- that should be enough. At one time GG emailed the ffmpeg group to ask for assistance with these as more could work if they were just set up by ffmpeg with initial values but they are so busy and Cinelerra is just another program. (Additional comment added later): However, the laptop I used is several years old and just because these 5 did not work for me, does not necessarily mean they do not work for other computer hardware setup.

1 1

GIT checkin of Masking enhancements +
by Phyllis Smith 28 May '19

28 May '19

The latest GIT checkin needs some more testing in Masking. Here is why. Masking was using OpenGL 1.x (1.2 or 1.4, not sure) and is now using OpenGL 4.3. This was a major accomplishment that took an entire week. Hopefully, everything works just fine but of some concern is the older operating systems. OpenGL 1.x came out in about 2002 and OpenGL 4.3 came out in 2012; so it is really old enough that even the older operating systems should have it installed, but not sure. The workaround for any system not up to version 4.3, is to use the X11 video driver for masking instead of X11-OpenGL. What is in this checkin? that was not noted in MantisBT #2: 1) Gang fade and feather has been added. This is a symbol to the right of those slider bars and looks like 2 links in a chain entwined. As you fade/feather one of the masks, the others will fade/feather accordingly up to a point (i.e. relative). 2) The fade and feather slider bars are now the same size in length. 3) Markers checkbox added to turn on/off the points for easier viewing. 4) Boundary checkbox added to turn on/off the boundary so as to not interfere with your view. 5) There is no longer a Mode button because now you can use the Fader slider to go positive (multiply) or negative (subtract) and it is a lot easier to use. Previously saved projects Mode should work as well and we did make an effort to test these. 6) The fade and feather sliders have a sticky spot near zero so it is easy to stop there. 7) make_shader rework -- this is not just in masking GG had to get this checked in as soon as possible to get more testing done before the end of the month builds, therefore all of the other changes that need to go in from the suggestions/bugs did not make it in. But hopefully will in a couple of days. An Ubuntu16 test build is at: https://www.cinelerra-gg.org/download/testing/cinelerra-5.1-ub16-x86_64-sta… Please report any anomalies if you happen to test. Thank you, Phyllis/GG

2 2

Your message to Cin awaits moderator approval ("French translation update")
by Olivier Humbert 27 May '19

27 May '19

Hi all and list moderators especially. Just letting you know that I posted a message (with a >400Kb file attached) to the list yesterday and I received the following automatic message : --------------- Your mail to 'Cin' with the subject French translation update Is being held until the list moderator can review it for approval. The reason it is being held: Message body is too big: 441440 bytes with a limit of 400 KB Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://lists.cinelerra-gg.org/mailman/confirm/cin/..... --------------- I'm mentioning it here for it not going unnoticed. Cheers, Olivier -- Site web : https://librazik.tuxfamily.org/ Donation : https://liberapay.com/LibraZiK/ Diaspora : https://framasphere.org/people/8c184af0c9450134f6682a0000053625 Mastodon : https://mastodon.xyz/@LibraZiK

4 5

Problem joining the forum
by John 27 May '19

27 May '19

Hey, I've tried to join the forum several times but never get the email for my password. Regards, John.

2 1

Speed curve
by Andrea paz 21 May '19

21 May '19

I don't know if it's a bug or my inability: How do I make the speed and camera/projector Z curve visible on the timeline? I activate the other curves and see them normally, these three are not.

2 1

Re: [Cin] SVT-AV1 0.5
by Andrew Randrianasulu 20 May '19

20 May '19

It seems you better use "-intra-period 30 -irefresh-type 2 " parameters for SvtAv1EncApp see https://github.com/OpenVisualCloud/SVT-AV1/issues/257 and https://trac.ffmpeg.org/ticket/7913 additionally, you can try to set libaom-av1 into speed mode by using cpu-used parameter - "0" is slower, "8" is fastest. Try "cpu-used" 5, according to graph at https://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=130284 libaom-git speed changes graph: https://www.reddit.com/r/AV1/comments/bpp15r/monthly_changes_in_the_speed_a… still in 0.1 fps range for high-quality (cpu-used=1), 1080p encodings on Ryzen 2400G ---------- Пересланное сообщение ---------- Тема: SVT-AV1 0.5 Дата: Воскресенье 19 мая 2019 Отправитель: Andrew Randrianasulu <randrianasulu(a)gmail.com> Получатель: "Cinelerra.GG" <cin(a)lists.cinelerra-gg.org> Hello, all!! Just read news at Phoronix: https://www.phoronix.com/scan.php?page=news_item&px=SVT-AV1-0.5.0-Released ------- SVT-AV1 0.5 is easily one of the fastest AV1 CPU-based video encoders and has been performing excellent in our tests, including continued daily benchmarks of it in keeping track of its performance. This open-source AV1 video encoder as of the v0.5 release supports 8/10-bit 4:2:0 encoding up to 4k60p resolutions, various presets, FFmpeg and GStreamer plug-in support, rate control support, various filters, tiling, 4/5 layer prediction structures, multi-reference picture support, and other features. -------- so I downloaded their release, and tried to build and test it on cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 21 model : 2 model name : AMD FX(tm)-4300 Quad-Core Processor stepping : 0 microcode : 0x6000852 cpu MHz : 1811.199 cache size : 2048 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 2 apicid : 16 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb cpb hw_pstate ssbd vmmcall bmi1 arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold bugs : fxsave_leak sysret_ss_attrs null_seg spectre_v1 spectre_v2 spec_store_bypass bogomips : 7599.47 TLB size : 1536 4K pages clflush size : 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro ffmpeg patch apparently for 4.1 branch, and whole software failed to build on 32-bit oS, yet it was ok on 64-bit Slackware 14.2 (gcc 5.5.0, yasm 1.3.0, cmake) root@slax:~/src/SVT-AV1-0.5.0/Bin/Release# ffmpeg -i /home/guest/20160802_185428.MOV -nostdin -f rawvideo -pix_fmt yuv420p - | ./SvtAv1EncApp -i stdin -n 100 -w 1280 -h 720 -b out.ivy ------------------------------------------- SVT-AV1 Encoder ffmpeg version 3.2.4 Copyright (c) 2000-2017 the FFmpeg developers built with gcc 5.5.0 (GCC) configuration: --prefix=/usr --libdir=/usr/lib64 --shlibdir=/usr/lib64 --docdir=/usr/doc/ffmpeg-3.2.4/html --mandir=/usr/man --disable-debug --enable-shared --disable-static --enable-gpl --enable-version3 --enable-avresample --arch=x86_64 --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-gnutls --enable-libcaca --enable-libcdio --enable-libssh --enable-libtheora --enable-libv4l2 --enable-libvorbis --enable-libvpx --enable-opengl --enable-libopenjpeg --enable-libpulse --enable-libsmbclient --enable-libwavpack --enable-x11grab libavutil 55. 34.101 / 55. 34.101 libavcodec 57. 64.101 / 57. 64.101 libavformat 57. 56.101 / 57. 56.101 libavdevice 57. 1.100 / 57. 1.100 libavfilter 6. 65.100 / 6. 65.100 libavresample 3. 1. 0 / 3. 1. 0 libswscale 4. 2.100 / 4. 2.100 libswresample 2. 3.100 / 2. 3.100 libpostproc 54. 1.100 / 54. 1.100 Guessed Channel Layout for Input Stream #0.1 : stereo Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '/home/guest/20160802_185428.MOV': Metadata: major_brand : qt minor_version : 0 compatible_brands: qt creation_time : 2016-08-02T18:54:28.000000Z Duration: 00:01:17.16, start: 0.000000, bitrate: 9895 kb/s Stream #0:0(eng): Video: h264 (High) (avc1 / 0x31637661), yuvj420p(pc, bt709), 1280x720, 8077 kb/s, 30.02 fps, 30 tbr, 90k tbn, 180k tbc (default) Metadata: creation_time : 2016-08-02T18:54:28.000000Z handler_name : iCat Alias Data Handler encoder : iCatch AVCC Stream #0:1(eng): Audio: pcm_s16le (sowt / 0x74776F73), 44100 Hz, stereo, s16, 1411 kb/s (default) Metadata: creation_time : 2016-08-02T18:54:28.000000Z handler_name : iCat Alias Data Handler [swscaler @ 0xf00de0] deprecated pixel format used, make sure you did set range correctly Output #0, rawvideo, to 'pipe:': Metadata: major_brand : qt minor_version : 0 compatible_brands: qt encoder : Lavf57.56.101 Stream #0:0(eng): Video: rawvideo (I420 / 0x30323449), yuv420p, 1280x720, q=2-31, 200 kb/s, 30 fps, 30 tbn, 30 tbc (default) Metadata: creation_time : 2016-08-02T18:54:28.000000Z handler_name : iCat Alias Data Handler encoder : Lavc57.64.101 rawvideo Stream mapping: Stream #0:0 -> #0:0 (h264 (native) -> rawvideo (native)) SVT [version]: SVT-AV1 Encoder Lib v0.5.0 SVT [build] : GCC 5.5.0 64 bit LIB Build date: May 19 2019 22:58:37 ------------------------------------------- Number of logical cores available: 4 Number of PPCS 72 ------------------------------------------- SVT [config]: Main Profile Tier (auto) Level (auto) SVT [config]: EncoderMode : 8 SVT [config]: EncoderBitDepth / EncoderColorFormat / CompressedTenBitFormat : 8 / 1 / 0 SVT [config]: SourceWidth / SourceHeight : 1280 / 720 SVT [config]: FrameRate / Gop Size : 30 / 32 SVT [config]: HierarchicalLevels / BaseLayerSwitchMode / PredStructure : 4 / 0 / 2 SVT [config]: BRC Mode / QP / LookaheadDistance / SceneChange : CQP / 50 / 33 / 0 ------------------------------------------- 100frame= 99 fps=3.3 q=-0.0 size= 133650kB time=00:00:03.30 bitrate=331776.0kbits/s speed=0.111x .0675x SUMMARY --------------------------------- Channel 1 -------------------------------- Total Frames Frame Rate Byte Count Bitrate 100 30.00 fps 1205227 2892.54 kbps Channel 1 Average Speed: 1.451 fps Total Encoding Time: 68915 ms Total Execution Time: 69845 ms Average Latency: 41891 ms Max Latency: 62157 ms Encoder finished Hm, 1.5 fps for 1280x720 , 30 fps video! (Note, encoding process really eats your CPU, everything started to lag, sound, mouse ...) Not bad ... next, I used ffmpeg-git for copying frames into mp4 container ffmpeg -i out.ivy -vcodec copy av1_svt_0.5.mp4 Resulting file was playable in my libdav1d patched Cinelerra-GG :} Also, libdav1d saw minor release 0.3.1 - featuring version for 0.3.1 · May 11, 2019 dav1d 0.3.1 'Sailfish', the fast and small AV1 decoder This is a small bugfix release fixing a decoding issue on SSSE3 CPU, when frame-threading is activated. It also reduces the binary size and gives more optimizations for SSSE3 src: https://code.videolan.org/videolan/dav1d/tags/0.3.1 -------------------------------------------------------

1 0

SVT-AV1 0.5
by Andrew Randrianasulu 19 May '19

19 May '19

Hello, all!! Just read news at Phoronix: https://www.phoronix.com/scan.php?page=news_item&px=SVT-AV1-0.5.0-Released ------- SVT-AV1 0.5 is easily one of the fastest AV1 CPU-based video encoders and has been performing excellent in our tests, including continued daily benchmarks of it in keeping track of its performance. This open-source AV1 video encoder as of the v0.5 release supports 8/10-bit 4:2:0 encoding up to 4k60p resolutions, various presets, FFmpeg and GStreamer plug-in support, rate control support, various filters, tiling, 4/5 layer prediction structures, multi-reference picture support, and other features. -------- so I downloaded their release, and tried to build and test it on cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 21 model : 2 model name : AMD FX(tm)-4300 Quad-Core Processor stepping : 0 microcode : 0x6000852 cpu MHz : 1811.199 cache size : 2048 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 2 apicid : 16 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb cpb hw_pstate ssbd vmmcall bmi1 arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold bugs : fxsave_leak sysret_ss_attrs null_seg spectre_v1 spectre_v2 spec_store_bypass bogomips : 7599.47 TLB size : 1536 4K pages clflush size : 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro ffmpeg patch apparently for 4.1 branch, and whole software failed to build on 32-bit oS, yet it was ok on 64-bit Slackware 14.2 (gcc 5.5.0, yasm 1.3.0, cmake) root@slax:~/src/SVT-AV1-0.5.0/Bin/Release# ffmpeg -i /home/guest/20160802_185428.MOV -nostdin -f rawvideo -pix_fmt yuv420p - | ./SvtAv1EncApp -i stdin -n 100 -w 1280 -h 720 -b out.ivy ------------------------------------------- SVT-AV1 Encoder ffmpeg version 3.2.4 Copyright (c) 2000-2017 the FFmpeg developers built with gcc 5.5.0 (GCC) configuration: --prefix=/usr --libdir=/usr/lib64 --shlibdir=/usr/lib64 --docdir=/usr/doc/ffmpeg-3.2.4/html --mandir=/usr/man --disable-debug --enable-shared --disable-static --enable-gpl --enable-version3 --enable-avresample --arch=x86_64 --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-gnutls --enable-libcaca --enable-libcdio --enable-libssh --enable-libtheora --enable-libv4l2 --enable-libvorbis --enable-libvpx --enable-opengl --enable-libopenjpeg --enable-libpulse --enable-libsmbclient --enable-libwavpack --enable-x11grab libavutil 55. 34.101 / 55. 34.101 libavcodec 57. 64.101 / 57. 64.101 libavformat 57. 56.101 / 57. 56.101 libavdevice 57. 1.100 / 57. 1.100 libavfilter 6. 65.100 / 6. 65.100 libavresample 3. 1. 0 / 3. 1. 0 libswscale 4. 2.100 / 4. 2.100 libswresample 2. 3.100 / 2. 3.100 libpostproc 54. 1.100 / 54. 1.100 Guessed Channel Layout for Input Stream #0.1 : stereo Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '/home/guest/20160802_185428.MOV': Metadata: major_brand : qt minor_version : 0 compatible_brands: qt creation_time : 2016-08-02T18:54:28.000000Z Duration: 00:01:17.16, start: 0.000000, bitrate: 9895 kb/s Stream #0:0(eng): Video: h264 (High) (avc1 / 0x31637661), yuvj420p(pc, bt709), 1280x720, 8077 kb/s, 30.02 fps, 30 tbr, 90k tbn, 180k tbc (default) Metadata: creation_time : 2016-08-02T18:54:28.000000Z handler_name : iCat Alias Data Handler encoder : iCatch AVCC Stream #0:1(eng): Audio: pcm_s16le (sowt / 0x74776F73), 44100 Hz, stereo, s16, 1411 kb/s (default) Metadata: creation_time : 2016-08-02T18:54:28.000000Z handler_name : iCat Alias Data Handler [swscaler @ 0xf00de0] deprecated pixel format used, make sure you did set range correctly Output #0, rawvideo, to 'pipe:': Metadata: major_brand : qt minor_version : 0 compatible_brands: qt encoder : Lavf57.56.101 Stream #0:0(eng): Video: rawvideo (I420 / 0x30323449), yuv420p, 1280x720, q=2-31, 200 kb/s, 30 fps, 30 tbn, 30 tbc (default) Metadata: creation_time : 2016-08-02T18:54:28.000000Z handler_name : iCat Alias Data Handler encoder : Lavc57.64.101 rawvideo Stream mapping: Stream #0:0 -> #0:0 (h264 (native) -> rawvideo (native)) SVT [version]: SVT-AV1 Encoder Lib v0.5.0 SVT [build] : GCC 5.5.0 64 bit LIB Build date: May 19 2019 22:58:37 ------------------------------------------- Number of logical cores available: 4 Number of PPCS 72 ------------------------------------------- SVT [config]: Main Profile Tier (auto) Level (auto) SVT [config]: EncoderMode : 8 SVT [config]: EncoderBitDepth / EncoderColorFormat / CompressedTenBitFormat : 8 / 1 / 0 SVT [config]: SourceWidth / SourceHeight : 1280 / 720 SVT [config]: FrameRate / Gop Size : 30 / 32 SVT [config]: HierarchicalLevels / BaseLayerSwitchMode / PredStructure : 4 / 0 / 2 SVT [config]: BRC Mode / QP / LookaheadDistance / SceneChange : CQP / 50 / 33 / 0 ------------------------------------------- 100frame= 99 fps=3.3 q=-0.0 size= 133650kB time=00:00:03.30 bitrate=331776.0kbits/s speed=0.111x .0675x SUMMARY --------------------------------- Channel 1 -------------------------------- Total Frames Frame Rate Byte Count Bitrate 100 30.00 fps 1205227 2892.54 kbps Channel 1 Average Speed: 1.451 fps Total Encoding Time: 68915 ms Total Execution Time: 69845 ms Average Latency: 41891 ms Max Latency: 62157 ms Encoder finished Hm, 1.5 fps for 1280x720 , 30 fps video! (Note, encoding process really eats your CPU, everything started to lag, sound, mouse ...) Not bad ... next, I used ffmpeg-git for copying frames into mp4 container ffmpeg -i out.ivy -vcodec copy av1_svt_0.5.mp4 Resulting file was playable in my libdav1d patched Cinelerra-GG :} Also, libdav1d saw minor release 0.3.1 - featuring version for 0.3.1 · May 11, 2019 dav1d 0.3.1 'Sailfish', the fast and small AV1 decoder This is a small bugfix release fixing a decoding issue on SSSE3 CPU, when frame-threading is activated. It also reduces the binary size and gives more optimizations for SSSE3 src: https://code.videolan.org/videolan/dav1d/tags/0.3.1

1 0

Observations using GPU on DNxHD and MPEG proxy while running CinelerraGG
by Phyllis Smith 17 May '19

17 May '19

This is an amalgamation of email from Pierre / me that should have been in the mailing list but I missed seeing that. *Summary first* in case you don't want to read it all. And just FYI, Pierre tests on Mint18 and I use Fedora29 with totally different processors, number of CPUs and even brand of graphics boards. 1) Pierre: I don't really see any gains either with X11 or X11-OpenGL, the viewing in the composer may be a little more fluid but I'm not sure ... shouldn't vdpau be able to decode these mpeg? 2) Phyllis: When you use X11-OpenGL, which was written long ago when there was mostly only 1 CPU so only 1 thread, the computer to the Graphics board can become bottlenecked with Cinelerra calling for OpenGL graphics and at the same time the GPU being used with vdpau (can not confirm that this is happening). 3) Pierre: I don't have the feeling that the GPU decodes video tracks under X11-OpenGL even in the case of mpeg proxies. 4) Phyllis: with certain hardware, I think you might be correct about GPU not doing the decoding under X11-OpenGL, but I can not find anything that corroborates that. I do see that with "loglevel=verbose" a vdpau device is created in either the X11 or the OpenGL driver case. But I am finding CPU usage is actually higher with the X11-OpenGL driver PLUS vdapu than X11-OpenGL MINUS vdpau with my computer hardware. 5) Phyllis: on computers with lots of CPU cores it does not seem worthwhile to bother with using the graphics board GPU for decoding. And that might apply to encoding too in the case of the final render because using the Render Farm (on a single computer with lots of cores) is pretty fast. *Pierre's Tests Results* (Intel computer with Nvidia graphics board) "DNxHD corrected.xml Test" file X11-OpenGL driver command CIN_HW_DEV=vdpau ./cin Proxys mpeg cpu % 21.6 - 43.7 frame/sec 11.18 - 12.16 DNxHD media cpu % 13.4 - 44.8 frame/sec 11.54 - 12.16 "DNxHD corrected.xml Test" file X11-OpenGL driver order /home/stone/Cinelerra-GG_5.1/cin Proxys mpeg cpu % 19.1 - 44.3 frame/sec 11.39 - 12.24 DNxHD media cpu % 19.6 - 44.5 frame/sec 11.32 - 12.16 "DNxHD corrected.xml Test" file X11 Pilot command CIN_HW_DEV=vdpau ./cin Proxys mpeg cpu % 19.5 - 41.7 frame/sec 29.97 - 30.15 DNxHD media cpu % 22.9 - 40.3 frame/sec 28.24 - 31.15 "DNxHD corrected.xml Test" file X11 Pilot order /home/stone/Cinelerra-GG_5.1/cin Proxys mpeg cpu % 23.08 - 42.4 frame/sec 29.97 - 31.02 DNxHD media cpu % 21.7 - 43.5 frame/sec 29.97 - 31.02 Interesting.... At first glance, I would say that: X11-OpenGL with or without vdpau Does not decode DNxHD sources Do not decode Proxys mpeg x11 with or without vdpau Decodes DNxHD sources Decode mpeg proxies I think I will now have to do some identical tests with HDV and H264.mp4 sources. *Short Phyllis tests (*AMD computer, Radeon graphics board) using the proxy Mpeg version, I see: 11% cpu usage with X11-OpenGL 13% cpu usage with X11-OpenGL + vdpau/GPU 16% cpu usage with X11 + vdpau/GPU 21% cpu usage with X11 *Most of the rest of the email thread is below.* Pierre Observation: I don't really see any gains either with X11 or X11-OpenGL, the viewing in the composer may be a lit tle more fluid but I'm not sure. I'm surprised that X11-OpenGL can't be fluid with mpeg.mpeg proxies, while it's much more fluid with Clowns' h264.mpeg and X11 does it all much better. But, as it is the mpeg.mpeg proxies that I actually use, shouldn't vdpau be able to decode these mpeg? Phyllis some response: So I had 4 dnxhd files from previous reports and I proxied them as 1/2 mpeg-s. Although it is not o bvious that they are using vdpau, they actually are. Bill reminded me to edit ffmpeg/decode.opts an d change "loglevel=fatal" to "loglevel=verbose", restart Cinelerra and then in the cinelerra startup window you will see messages for the Mpegs: (you might have to also edit bin/ffmpeg/decode.opts ) [AVHWDeviceContext @ 0x7fff182c3cc0] Successfully created a VDPAU device (G3DVL VDPAU Driver Shared Library version 1.0) on X11 display :0 [AVHWDeviceContext @ 0x7ffea8afc980] Successfully created a VDPAU device (G3DVL VDPAU Driver Shared Library version 1.0) on X11 display :0 [AVHWDeviceContext @ 0x7fff6c1b12c0] Successfully created a VDPAU device (G3DVL VDPAU Driver Shared Library version 1.0) on X11 display :0 [AVHWDeviceContext @ 0x7fff6f223300] Successfully created a VDPAU device (G3DVL VDPAU Driver Shared Library version 1.0) on X11 display :0 When you use X11-OpenGL, which was written long ago when there was mostly only 1 CPU so only 1 threa d, the computer to the Graphics board can become bottlenecked with Cinelerra calling for OpenGL grap hics and at the same time the GPU being used with vdpau. ---------------------------------------------------------------------------------------------- Pierre Observation: What surprises me though is that this difficulty does not exist under X11; the accumulation of video tracks from mixers does not cause the composer to slow down under this video driver.When I play DNxHD sources the CPU usage is 37-41%, If I play proxies in mpeg, the CPU usage is 10-18%. But in both cases (DNxHD and proxies in mpeg), the frame rate (in CinGG's preferences) is 11-12 frame/s (whereas the normal rate should be 29.97 frame/s). Phyllis some response: When I play it, X11-OpenGL slows down so that the mixers are done playing and compositor is only on frame 106; but with X11 I still have slow down, just not as bad. The mixers are done playing but th e compositor is still playing at about frame 175 - so for me X11 does still have the difficulty. I suspect that your computer is faster with more cores. For example, with X11-OpenGL, if I run the "top" command from another window and watch it, I see it goes to 489% so is using threads/multiple c ores BUT it must be waiting on the single threaded Graphics Board. Since when I just use X11, the p rogram is not waiting on the graphics boards and runs at 600%. The graphics board is likely a bottl eneck. --------------------------------------------------------------------------------------------------- Pierre Observation: Under the X11 video driver: With DNxHD, the CPU is at 35% and the frame rate at 29.97-30 frame/s With Proxys in mpeg, the CPU is at 6.5-10.9% and the frame rate is also at 29.97-30 frame/s. I don't have the feeling that the GPU decodes video tracks under X11-OpenGL even in the case of mpeg proxies. Secondly, Under the X11-OpenGL video driver: When I play DNxHD sources the CPU usage is 37-41%, If I play proxies in mpeg, the CPU usage is 10-18%. But in both cases (DNxHD and proxies in mpeg), the frame rate (in CinGG's preferences) is 11-12 frame/s (whereas the normal rate should be 29.97 frame/s). Phyllis some response: Unfortunately, I am not seeing this. For example with: EX-EGO Test DNxHD/Cam-4_MVI_1321_EX-EGO_cam-D.mov I see 29.97 fps in preferences and 60% CPU EX-EGO Test DNxHD/Cam-4_MVI_1321_EX-EGO_cam-D.proxy2-mov.mpeg and here I see 29.97 fps and 70% CPU Something else must be causing the problem you see. GG noticed that these DNxHD sources are very large in size but I do not think that the disk I/O would slow anything down. I think you might be correct about GPU not doing the decoding under X11-OpenGL, but I can not find anything that corroborates that. I do see that with "loglevel=verbose" a vdpau device is created in either the X11 or the OpenGL driver case. But I am finding CPU usage is actually higher with the X11-OpenGL driver PLUS vdapu than X11-OpenGL MINUS vdpau. So I thought it was a really bad idea to use OpenGL and GPU/vdpau together. However, Sam and Andrea thought they got better results using X11-OpenGL than X11 with vdpau enabled. This has been mystifying to me as I definitely only saw good improvements using X11. Since we can not figure it out, I have decided that it might be due to the actual Graphics Card being used in conjunction with the Nvidia driver and operating system. Summary - on computers with lots of CPU cores it does not seem worthwhile to bother with using the graphics board GPU for decoding. And that probably applies to encoding too in the case of the final render because using the Render Farm (on a single computer with an Epyc chip) is so fast as to be trivial. ------------------------------------------------------------------------------------------------------------ Pierre tests on the following: The processor of my computer is an i7-3770k, so it has 4 physical core, 8 threads by Hyper-Threading (2 processing threads per physical core) at 3.50 GHz (turbo 3.90 GHz). 32 GB of ram and an nVidia GTX-750ti extension video card. The nVidia card, which is a few years old, is not very powerful for aespecially useful to me because of its ability to manage 4 monitors 1920x1080 simultaneously. In my case, it is connected to three monitors. I therefore suspect that this video card does not offer a significantly greater performance gain than the possibilities of my CPU... Phyllis tests on the following: AMD 8-Core RYZEN 7 1700 Processor, 3.0 GHz cache size : 512 KB memory : 64 GB Radeon Graphics Board : Radeon RX580 4GB gamer type card (the really powerful models have become extremely expensive since the arrival of bitcoin mining...). This video card is

7 17