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

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
live-devel mailing list
[email protected]
http://lists.live555.com/mailman/listinfo/live-devel

Reply via email to