Re: [xine-devel] What is a Discontinuity?

[Miguel F. <mi...@ce...>]

Hi Mike,

On Sun, 2002-05-26 at 00:52, Mike Melanson wrote:
> Hi,
> 	So I have been fighting with xine-lib, trying to write a
> demuxer. The general strategy looks like this:
> 
> - demux_open() function detects if it is the right type of file
> - demux_start() digs through the file and finds the important table of
> sample values and builds an index consisting, for each sample, of:
>   - sample offset
>   - sample size
>   - PTS in reference to a 90 kHz clock
>   - keyframe flag
> demux_start() then issues start commands to the buffers 
> (BUF_CONTROL_START), followed by init packets to both decoders. Then, it 
> spins off a new thread:
> - demux_loop() iterates through the sample table from start to finish
> (pretend I am trying to keep this simple and not worrying about seeking
> yet), building up audio or video packets with data, size, pts, and flags
> and dispatching them to the decoders via the fifos.
> 
> 	It does not work.

It looks fine, don't you have any idea of what's going wrong? if you
send the console messages and/or the source we may try to guess
something... The only missing bits that occured me are the ability to
start() with given position and sending NEWPTS bufs (see below).

Also, copying the existing code from other demuxers is a good idea...

> Some questions:
> - The main problem has something to do with discontinuities, but I do not
> know what that means in the context of xine. What are they? Where and why
> does the BUF_CONTROL_NEWPTS message come into play? What do I need to know
> about discontinuities to make this demuxer work?

It's up to the demuxers to inform metronom about discontinuities in pts
values. Some stream types, most notably mpeg, may wrap pts values
without further notice. demuxer should know better how to detect these
things.

For most streams however there will be no discontinuities at all. Even
these _MUST_ send a BUF_CONTROL_NEWPTS on every start or seeking. This
control buffer will adjust metronom's variables so vpts (xine virtual
pts values -- always increasing) will be a little ahead of current time.
If you don't send BUF_CONTROL_NEWPTS, the vpts can be so wrong that xine
would drop everything or wait forever before displaying your data... 
 
> - The buffer structure has a member called input_pos; is this just the
> file offset in the case of reading from the file? Why would a decoder care
> about that?

Yes, the decoder doesn't care at all. It's just used for drawing slider
position i guess.
    buf->input_pos  = this->input->get_current_pos(this->input);

> 	That is all I can think of for now. Thanks...

Ok, let us know if you need something...

regards,

Miguel