[vlc-devel] commit: Clean up the code a bit, turning to be half as laggy as the previous code, but it will need to be properly fixed. ( Felix Paul Kühne )

Felix Paul Kühne fkuehne.videolan at googlemail.com
Thu Jun 12 19:44:57 CEST 2008

Hash: SHA1

On 12.06.2008, at 12:56, Pierre d'Herbemont wrote:

> Any reason for that? No need to malloc() the p_sys if we can't probe
> it... Not a big deal, but...
That's because I'm using p_sys's capture objects (session, device, ..)  
directly without allocating temporary objects in Open(). Should be  
faster and less memory consuming, even if we need to allocate the  
p_sys first. The actual init is still done after successfully  
detecting an input device.

> ...This is wrong. In case of error you end up in a double free.
Ah, that's true. I'll fix that later today.

> No need to lock here. Why would you do that copyCurrentFrameToBuffer:?
> already takes care of that.
That's what I thought too, but apparently locking here and waiting for  
the p_block to be complete gives a speed up of about 25 to 35 pro  
cent, meaning less but still noticeable delay.

>> -        currentPts = [sampleBuffer presentationTime].timeValue /
>> [sampleBuffer presentationTime].timeScale;
>> +        currentPts = [sampleBuffer presentationTime].timeValue;
By using mtime_t for currentPts, we are loosing a lot of precision in  
the long run if we do this division here, so I removed it. This  
doesn't affect our time stamps at all actually because of the pts =  
mdate() later on the code, which should be removed too IMO.


Version: GnuPG v1.4.8 (Darwin)


More information about the vlc-devel mailing list