<p><br>
On May 30, 2014 12:20 AM, "Steve Borho" <<a href="mailto:steve@borho.org">steve@borho.org</a>> wrote:<br>
><br>
> On Thu, May 29, 2014 at 1:43 PM, Aarthi Priya Thirumalai<br>
> <<a href="mailto:aarthi@multicorewareinc.com">aarthi@multicorewareinc.com</a>> wrote:<br>
> > initially both frameNumThreads and m_totalFrameThreads are set to same value<br>
> > specificed by user. So, we are always  creating frameEncoder objects,<br>
> > frameNumThreads holds actual frame thread count.<br>
> > Only when we begin to encode, we change the value n within that second we<br>
> > reset it to orig num of frame threads. So , the destroy func called at very<br>
> > end can use frameNumThreads safely. Logically, There shouldn't be memory<br>
> > leaks here..<br>
><br>
> If the clip is less than half a second long?</p>
<p>:) ok. <br>
><br>
> --<br>
> Steve Borho<br>
> _______________________________________________<br>
> x265-devel mailing list<br>
> <a href="mailto:x265-devel@videolan.org">x265-devel@videolan.org</a><br>
> <a href="https://mailman.videolan.org/listinfo/x265-devel">https://mailman.videolan.org/listinfo/x265-devel</a><br>
</p>