[Live-devel] RTP packet lost whenLive555MediaServerstreamsforward Dektec DTE3114

[Lambert Marc]

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 : live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] 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
live-devel at lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel