[vlc-devel] Re: Need some help writing a demux module

[Derk-Jan Hartman]

On 01 okt 2004, at 04:58, Chris Douty wrote:
> Hi VLC gurus,
>
> First off, you all have my thanks for making this extremely versatile 
> media player.
>
> Now, I have some questions about writing a module from the perspective 
> of a total neophyte up against a time wall.  My goal is to write two 
> modules for our multiplexer/solid state recorder.  As a mux we create 
> a particular format file that happens to contain a MPEG-2 TS along 
> with a bunch of other junk. (non-audio PCM, gps readings, occasional 
> timestamps, Death Star plans, etc.)  The other module will be an 
> access module to connect directly to the recorder and read the data 
> over a TCP/IP network.  Since I can download files from the recorder 
> to a normal filesystem and the demux module is required to understand 
> the data, I am working on it first.

So you are working with Yet Another Custom Wrapper Fileformat :)
Those are soooo stupid.

> My plan is to use the new stream_Demux*() functions to create a sub 
> demux for the TS stream which my module would feed.  So far I can 
> register and load my new demux and spawn either the 'demuxdump' or 
> 'ts' as slave threads.  I think that I've figured out most of the 
> requirements for a well-behaved module by examining many of the other 
> modules and a lot of libvlc code.  (Gee, I wish the API docs and 
> developer's guide were up to date. :-)

Yeah i agree on that :)

> What I don't understand is how flow control or rate limiting works.  
> As a gross hack I inserted a msleep(10000) call in my Demux() function 
> right after I call stream_DemuxSend().  If I don't do that then the ts 
> module never gets beyond reading a few 188 byte packets before I 
> overflow the buffer.  I don't think that I am handling eof correctly 
> either.  To me it looks like the 'input' thread calls my Demux 
> function as fast as it can, while the spawned 'stream out' thread does 
> the same thing.  My msleep() call and a carefully tuned block size 
> let's the player kinda work, but it's clearly not right.
> What am I missing?  How does rate control work?  Do I need to try to 
> feed the clock? and what?

You see, this is where these fileformats go wrong. In VLC rate control 
is based on the timestamping info in your input. And your fileformat 
probably doesn't have that. The TS has it, but currently sub demux 
cannot do the rate controlling. So therefore there is no way this can 
work. Or you need to have some custom time stamping which can be used. 
a demux should present data to the decoder at a certain time and this 
time is usually based on the timestamps in media files.

What you can do is either specify the rate yourself (which you are 
sorta doing with your msleep), or retrieve the rate from the TS and put 
that in your custom fileformat on the server. Both are suboptimal 
solutions. It would be better to just provide the TS on the server 
separately instead of wrapping it, but perhaps you have no control over 
that.

Another solution i cannot see atm.

> I am also unsure how to respond to the various demux_query_e messages. 
>  My base multiplex has a periodic time packet, but doesn't have a 
> constant bit rate.  For simplicity's sake I don't think that I will 
> allow seeking on my access module, at least at first.

same story kinda.

---
Universiteit Twente
Derk-Jan Hartman (d.hartman at student.utwente dot nl)
http://home.student.utwente.nl/d.hartman

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