<div dir="auto">may be this?<div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><a href="https://www.cinelerra-gg.org/bugtracker/view.php?id=504">https://www.cinelerra-gg.org/bugtracker/view.php?id=504</a><br></div><div dir="auto"><br></div><div dir="auto">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?)</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">пн, 30 янв. 2023 г., 14:16 Stefan de Konink via Cin <<a href="mailto:cin@lists.cinelerra-gg.org">cin@lists.cinelerra-gg.org</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Monday, January 30, 2023 11:16:03 AM CET, Stefan de Konink via Cin <br>
wrote:<br>
> If it would help I am happy to create some projects 'as bugs' <br>
> for QA-purposes.<br>
<br>
The ultimate cause of the mentioned issue is the cache size (Preference > <br>
Performance > Cache size (MB)) being reduced to 1MB. When increasing it <br>
back to the default value of 256 the issue is mitigated.<br>
<br>
But I do wonder: does this uncover a performance issue that should be <br>
documented? Would it really take a full second to compute the frame order?<br>
<br>
-- <br>
Stefan<br>
-- <br>
Cin mailing list<br>
<a href="mailto:Cin@lists.cinelerra-gg.org" target="_blank" rel="noreferrer">Cin@lists.cinelerra-gg.org</a><br>
<a href="https://lists.cinelerra-gg.org/mailman/listinfo/cin" rel="noreferrer noreferrer" target="_blank">https://lists.cinelerra-gg.org/mailman/listinfo/cin</a><br>
</blockquote></div>