[Live-devel] FramedFilter Performance & Questions

[Julian Lamberty]

OK, I've investigated the problem further by adding timestamp at the 
beginning and the end of doGetNextFrame(), afterGettingFrame() and 
afterGettingFrame1(). As you can see from the code snippet in this 
thread, everytime my transcoder needs more data to complete the frame it 
calls fInputSource->getNextFrame(..., afterGettingFrame, ...). 
afterGettingFrame1() actually encapsulates the transcoding funstions.

No I've added the timestamps (all in ms) and got the following output 
(similar for every frame):

Transcoder::doGetNextFrame() start: 1182779980073.611084
Transcoder::doGetNextFrame() end: 1182779980073.627930
Transcoder::afterGetttingFrame() start: 1182779980073.635986
Transcoder::afterGetttingFrame1() start: 1182779980073.643066
Transcoder::afterGettingFrame1() end: 1182779980073.673096
Transcoder::afterGettingFrame() end: 1182779980073.679932

...(timestamps are very close here)...

Transcoder::afterGettingFrame1() end: 1182779980073.902100
*Transcoder::afterGettingFrame() end: 1182779980073.907959*
*Transcoder::afterGetttingFrame() start: 1182779980096.835938*
Transcoder::afterGetttingFrame1() start: 1182779980096.875000

Decoded frame    2 [B,   9140 Bytes] in 13.95 ms
[mpeg4 @ 0xb7e14144]warning, too many b frames in a row
Encoded frame    2 [P,  16834 Bytes] in 12.15 ms, PSNR = 48.86 dB
Total frame processing time 49.47 ms

Transcoder::afterGettingFrame1() end: 1182779980123.104980
Transcoder::afterGettingFrame() end: 1182779980123.113037
Transcoder::doGetNextFrame() start: 1182779980127.437012

As you can see at the marked position, there is a gap of about 23ms just 
before the frame is completely decodable, timestamps before and after 
this position seem to be OK to me. Why is this gap there and where does 
it come from? Why is the last call to afterGettingFrame delayed and the 
other calls are not? Am I doing something wrong or does the parsing of 
the final slice (by MPEG1or2VideoRTPSource) take so much time?

I really don't get where these 23ms come from, thats actually as much as 
I need for decoding and encoding... :(

Thanks for your help
Julian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5198 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.live555.com/pipermail/live-devel/attachments/20070625/8b1f880f/attachment.bin