[vlc-devel] Re: vlc: svn commit r13220 (md)

[Marian Durkovic]

> Where did you see that CR_MAX_GAP was in microseconds ?

There are other examples which already consider something > 2 seconds a "hole"
For example in modules/access_output/udp.c:

        i_date = p_thread->i_caching + p_pk->i_dts;
        if( i_date_last > 0 )
        {
            if( i_date - i_date_last > 2000000 )
            {
                if( !i_dropped_packets )
                    msg_Dbg( p_thread, "mmh, hole ("I64Fd" > 2s) -> drop",
                             i_date - i_date_last );

> Yep, 22 seconds was exactly what was wanted.

Then there is a serious problem for VLC's streaming using any kind of RTP
or RAW UDP. MPEG-TS requires PCRs every 100 msec, and streams received
via livedotcom will have PCRs extracted from RTP timestamps of RTP packets.
Leaving upto 22 second gaps undetected is very bad here... 
Imagine what happens if e.g. livedotcom receives the first RTCP report with 
20 seconds ofset - do we really want to stop playback for 20 seconds and
buffer all those data ???

> Assuming you'll always have less than 2 seconds between 2 received PCRs 
> isn't sensible. It might be for well formed MPEGs but it won't be for other 
> kind of streams.

OK, if this is the case, I'll revert the commit and create a ticket, since
this is IMHO a serious problem. Anyway, could you perhaps post the typical 
time diffs between PCRs for other kind of streams you're talking about? 

> What you're doing wrong is, as I already stated, that you can't do input 
> clock gap detection based on our internal clock.
> The input clock gap detection is supposed to be based on the input clock and 
> nothing else.

OK, I see, so instead of i_rate there should be INPUT_RATE_DEFAULT.


	With kind regards,

		M.

-- 
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html