[CinCV TNG] Benchmarking different versions of Cinelerra?

Andrew Randrianasulu randrianasulu at gmail.com
Wed Jul 19 21:01:22 CEST 2017


В сообщении от Wednesday 19 July 2017 20:12:01 Einar Rc3bcnkaru написал(а):
> On 07/19/2017 09:49 AM, Andrew Randrianasulu wrote:
> > В сообщении от 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.
>
> We lack people who do something for cinelerra. So I had to ask directly
>
> > 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?).
>
> Never tried hw-accelerated decodinig, but I have read that they are not
> high qualty.


well, only working for  me partial decode acceleration looks OK. There are 
well-known artefacts for nouveau/vdpau/mpeg2 combination - but they simply 
software bugs. Sadly, writing firmware for those  video decoding coprocessors 
is even bigger task than 'just' reverse-engeneer rendrering part of GPU. AMD 
run proprietary video decoding firmware, and nouveau so far relies on extracted 
binary firmware for  this hardware decoding (ok, my card has TWO video 
decoders, one is fixed-function mpeg2 decoder, and this run w/o host-uploaded 
firmware, and near it you have again, combination of TWO dirrerent 
coprocessors, one running bitstream processing, and other doing 
massively-parallel run on partially-decoded image. For some yet to discovered 
reason bitstream processor hang at, hm, decoding h264 bitstream, with 
nouveau..) So, while in theory quality can be improved due to programmable 
nature of those co-processors - none was able to demonstrate this yet.

>
> I think that hw-accelerated decoding is developed for workflow
> decode-play. But Cinelerra needs workflow decode - convert to internal
> format - modify - convert to playback format - play. The question is how
> effective is getting decoded frame from hardware - there may be
> bottleneck. And the bottleneck may depend on hardware model.
yeah. and even if today I have pci-e 2.0 motherboard - moving data back and 
forth will surely kill performance..BUT it hit me just now - wasn't same 
problem existed to some degree in renderfarm secenario? When one Cinelerra send 
frames to process to other Cinelerra instances over relatively slow (compared 
to local shared mem communication) network link, and need to get them back for 
integrating at one place?

>
> > 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?
>
> There may be a lot of I-only codecs, but there is a lot of other codecs
> too. My imagination is that input can be I-frames only, but output will
> be usually some other effectively compressed format.
>
> > 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, IMO)
>
> I know, that I write too few comments, I'll try to improve myself.

Thanks!
>
> Thanks,
> 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