Thanks... You are right It is not a good idea to ignore RTCP corrections...
I have no problem with viewing...I just push incoming streams [ since they are from real time ip camera ] to decoder than viewer, I can see the video Since my rtsp source is in real time i do not insert any time-stamp or presentation time before sending them to decoder... My timestamps problems start when i try to write them to MP4[container] file using an MP4 muxer... Because of MP4 container format i have set their presentation time to muxer otherwise i have a broken MP4 file... so first i calculate firstPresentationTime TIMEVAL_TO_REFERENCE_TIME(presentationTime); // at first frame[key frame] then push muxer other frames time stamps as follow TIMEVAL_TO_REFERENCE_TIME(presentationTime) - firstPresentationTime; Jeremy Noring warn me about my TIMEVAL_TO_REFERENCE_TIME so i fixit :(there is overflow) as #define TIMEVAL_TO_REFERENCE_TIME(x) (((__int64)x.tv_sec * 1000000) + x.tv_usec) * 10 For now it seems to work in a correct way... But anyway if anybody write h264 stream to MP4 container using a MP4 muxer, i will like to hear their advices about timestamps calculations. Best Wishes 2011/12/22 Ross Finlayson <finlay...@live555.com>: > My RTSP Source's RTCP SR are not reliable... > > > You are probably mistaken. > > So calculated timestamps frequently resulting in large negative jumps. > > > Let me guess: You're receiving H.264 (or MPEG) video that uses "P" > (prediction) frames. For video streams like this, frames are sent (and thus > received) in 'decoding order' - i.e., the order that they will be fed to a > decoder, not 'presentation order' - the order that they will be displayed on > the screen. In this case, it is normal (and expected) that the received > frames' presentation times will not all be monotonically increasing. The > incoming frames should be fed into your decoder in the order that they > arrive, but their presentation times will tell you when they should be > displayed. > > But in any case, RTCP is an important part of the RTP/RTCP protocol, and > should not be disabled. > > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > > _______________________________________________ > live-devel mailing list > live-devel@lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > _______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
