YES !!! At last, I found how to do, I reduced MAX_PLAYOUT_BUFFER_DURATION from 0.1 to 0.001 second and it works fine. Actually, the value at 0.1 allows to have a gap about 100ms between the estimated rate and the output rate, it is too high for the DTE-3114. With this value at 0.001, the computation turns all the time around 0 (from -0.005 to 0.005) and it is perfect.
-----Message d'origine----- De : Lambert Marc Envoyé : mardi 13 juillet 2010 18:37 À : Lambert Marc; 'LIVE555 Streaming Media - development & use' Objet : RE: [Live-devel] RTP packet lost whenLive555MediaServerstreamsforward Dektec DTE3114 After some new tests, if I modify NEW_DURATION_WEIGHT, TIME_ADJUSTMENT_FACTOR or PCR_PERIOD_VARIATION_RATIO, nothing becomes right but I defined DEBUG_PCR and when macroblocks happen, I can see a variation on the estimation of the PCR. Most of the time, it is at 162 and regularly it decreases at 108, then increases at 268 and comes back at 162. "this duration" stays at 162 all the time... Do you know what it means ? -----Message d'origine----- De : Lambert Marc Envoyé : mardi 13 juillet 2010 17:58 À : LIVE555 Streaming Media - development & use Objet : RE: [Live-devel] RTP packet lost whenLive555MediaServerstreamsforward Dektec DTE3114 At last, I have an answer from dektec supprt. Actually, it's clear than the .ts file is correct and the PCR is perfect, the outgoing RTP packet are also perfect but there is a very small mismatching between the bandwidth and the PCR during approximativelly 75 seconds afterwhat the bandwidth and the PCR match. We have tryed with many files and it seems to be all the time the case. I also pinpoint than the DTE-3114 doesn't treat the RTP header, actually, it works like it would receive UDP packets, then it only referrence is the TS PCR and the broadcasting is only done with it. It explains why there is a buffer overflow sometimes until the PCR and the RTP bandwidth match. Then, I would like to know how to do to speed up the bandwidth computation from the PCR because it is approximativelly computed at the beginning and it take many seconds to decrease forward the correct bandwidth by about 100KHz steps. I'm going to try on my side to touch the algorism using NEW_DURATION_WEIGHT and TIME_ADJUSTMENT_FACTOR but I'm not sure to well understand how it works. -----Message d'origine----- De : [email protected] [mailto:[email protected]] De la part de Ross Finlayson Envoyé : lundi 12 juillet 2010 20:58 À : LIVE555 Streaming Media - development & use Objet : Re: [Live-devel] RTP packet lost whenLive555MediaServerstreamsforward Dektec DTE3114 >You shouldn't try to modify the code of the library unless you find a bug. Yes, thank you Guy! > The library send the packets at the appropriate time following the >RTP specification unless the OS timer resolution create an issue. Marc, what OS are you using? If you are using Windows, then it's likely that your timer's resolution is too coarse; I've seen other people (not just Guy) who have had this problem with Windows. (Personally, I don't understand why anyone uses Windows to run an embedded system. Unix (including Linux) systems are much much better for this purpose.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ _______________________________________________ live-devel mailing list [email protected] http://lists.live555.com/mailman/listinfo/live-devel _______________________________________________ live-devel mailing list [email protected] http://lists.live555.com/mailman/listinfo/live-devel
