[CinCV TNG] Benchmarking different versions of Cinelerra?

Andrew Randrianasulu randrianasulu at gmail.com
Wed Jul 19 08:49:22 CEST 2017

В сообщении от Tuesday 18 July 2017 23:26:25 Einar Rc3bcnkaru написал(а):
> On 07/18/2017 09:43 PM, Andrew Randrianasulu wrote:
> > Hi, all!
> >
> > I tried to compare playback performance between three different versions
> > of Cinelerra, but as Einar correctly warned - benchmarking is not simple!
> > While for my system some parameters like visible track size
> > (32->64->128), and resolution of timeline doesn't play such big
> > difference - on other systems they may slow down things more or less,
> > compared to decoding/effect
> > computations/encoding.
> >
> > So, may be standartized set of Cinelerra (CV | CVE | GG) config files can
> > be developed, along with publically-accesible test videos in various
> > formats?
> Andrew, start creating.

Yes, I see irony/light sarcasm here.
I used dreamtime.mpg from 
https://samples.ffmpeg.org/HDTV/ for some benchmarks, and also 
http://www.w6rz.net/1080p25.zip (mpeg2) found at this forum page

(some links probably not functionating anymore, but I checked 1080.zip file just 

Of course they often not directly consumable by 'classical' (libquicktime-based) 
Cinelerra -  but they can be remuxed/reencoded locally via 

As for Cinelerra's own settings - I was more thinking about revisiting default 
settings between all three active branches (they all already default for X11_xv 
video output, and ALSA as audio output, all open four windows, set 10Mb cache, 
and this is good)

> > Also, I was wrong in my observation only CVE was not utilizing all four
> > cores to 100% during playback-only - they all mostly load cores to 80-90%
> > - so hopefully there is some room for improvements.
> Probably not much. Threads have to wait after each other too. They are
> not completely indpendant.
> Thogh encoding or playback speed is not so important when there are
> effects that may take seconds to render one frame.

Yeah ...for example 'gamma' effect was very slow.
I was thinking about those kind of improvements - they not big in absolute, but 
they accumulate over time, and made ffmpeg still quite damn fast software 
de/encoder around:

("[FFmpeg-devel] [PATCH 1/3] avutil: merge slice threading implementation from 
avcodec and avfilter" and two other patches from same series)

Well, right now Cinelerra 5.1 (GG) provides good integration of ffmpeg's filters 
subsystem, and  may be one day hw decoding/filtering will be implemented, too  
(but do developers of Cinelerra have required hardware? va-api today exposed on 
Intel and AMD GPUs, and partially on _some_ Nvidia cards via VA_API state 
tracker (open source driver). I mean here decoding side of it, not encoding. 
But Cinelerra already can output processed frames to external encoder, and this 
encoder can be hw-accelerated ffmpeg, right?). Einar's branch  shows some 
impressive array of user-accessible codec settings - hopefully one day this  
ability to fine-tune de/encoding will see some good use.

Speaking about recently-removed direct_copy mechanism - I definitely will not 
object to reimplementation of it on top of (or more accurately - inside?) 
AVlibs, because  modern ffmpeg provides more I-only codecs, and those codecs 
will be accessible via AVlibs for both de- and en- coding. But this is question 
of architecture - can I kndly ask Einar to keep this future use of *new* direct 
copy in mind, while working on all those abstraction features like Vframe etc?

Also, please leave more comments in code - I found reading simple english 
comments inside source files in quicktime directory very educational. (even if 
not helpful by now, when ffmpeg grow much better number {and better quiality!} 
of de/muxers and de/coders, and become sort of thing libquicktime tried to be, 

> Einar
> _______________________________________________
> Cinelerra mailing list
> Cinelerra at lists.cinelerra-cv.org
> http://lists.cinelerra-cv.org/cgi-bin/mailman/listinfo/cinelerra

More information about the Cinelerra mailing list