Thanks Jeremy .. You are right...Fool me..I make the classic mistake... And this may cause my timestamp radical jumps...I will test it...
Best Wishes 2011/12/22 Jeremy Noring <kid...@gmail.com>: > On Sat, Dec 17, 2011 at 5:19 AM, 6.45 6.45.Vapuru <6.45.vap...@gmail.com> > wrote: >> >> Hi >> >> I modify the OpenRtspClient so that >> >> -- Now instead of writing frames to file I collect them in a queue >> with incoming presenttaion times >> -- Then give the h264 frames to MP4 muxer [ Geraint Davies MP4 mux filter] >> -- Finally write muxed data to file... >> >> So I can able to save h264 stream into MP4 container... >> But the problem is that, some of the recorded data [NOT all of them] >> has wrong values for time duration: >> Suppose that a 10 minute record seems that it was 12 h stream... >> VLC play the 10 minute that play last frame for the remaing time. > > > First thing that comes to mind is you have an obvious overflow issue: > > > #define TIMEVAL_TO_REFERENCE_TIME(x) ((__int64)(x.tv_sec * 1000000) + > x.tv_usec) * 10 > > ...x.ty_sec and x.ty_usec are 32-bit signed (long). You multimply x.tv_sec > by 1,000,000, and *then* cast to __int64. So you'll overflow that in about > ~2147 seconds. You need to cast to __int64 *first* and then do your > multiplication. This probably explains the weird jumping. > > > _______________________________________________ > 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
