[Cin] Rendering 57min of material takes over 12 hours

Andrew Randrianasulu randrianasulu at gmail.com
Mon Jan 30 14:14:17 CET 2023

may be this?


not sure if we can speed up decoding in libavcoded - mplayer seems to seek
much faster but I guess it can skip decoding whole frames for that and our
pipeline not ready for this, because how you will deal with empty frames
after such fast seeking? I mean you can hit any frame in arbitrary place,
so decoding it due to b and p frames might take a while, so randomly-placed
edit probably seeks/decodes a lot just for avoiding empty frm problem
(while for playback there is toggle about playing every frame or not. But I
think it only drops at output?)

пн, 30 янв. 2023 г., 14:16 Stefan de Konink via Cin <
cin at lists.cinelerra-gg.org>:

> On Monday, January 30, 2023 11:16:03 AM CET, Stefan de Konink via Cin
> wrote:
> > If it would help I am happy to create some projects 'as bugs'
> > for QA-purposes.
> The ultimate cause of the mentioned issue is the cache size (Preference >
> Performance > Cache size (MB)) being reduced to 1MB. When increasing it
> back to the default value of 256 the issue is mitigated.
> But I do wonder: does this uncover a performance issue that should be
> documented? Would it really take a full second to compute the frame order?
> --
> Stefan
> --
> Cin mailing list
> Cin at lists.cinelerra-gg.org
> https://lists.cinelerra-gg.org/mailman/listinfo/cin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20230130/08ab17b2/attachment.htm>

More information about the Cin mailing list