[pvrusb2] MPEG stream distribution

[Mike Isely]

On Fri, 17 Feb 2006, Phil Endecott wrote:

> Dear All,
>
> I have been writing some code to distribute an MPEG stream (e.g. from
> the PVRUSB2's /dev/video0) to multiple applications.  (Normally it's not
> possible for more than one process to read from /dev/video0
> simultaneously.)  My code is a simple daemon that opens the input stream
> and accepts TCP connections; each TCP connection gets sent what's
> arriving from the input at that time.  It would be good if the
> connections could be via filesystem nodes rather than TCP sockets; any
> ideas how to do that?

Unix sockets.  Look for information on the AF_UNIX address family.


>
> My intention is to add some code to perform synchronisation when a new
> connection is made, i.e. to wait for the next I-frame before starting to
> send data.  But I don't know enough about the MPEG format to do that
> yet, and the applications that I've tried don't seem to complain much
> about being dropped in to the middle of the stream.
>
> One reason why I want this is so that I can capture single-frame
> snapshots without stopping whatever else is listening.  To help with
> this I have another short program that tries to read exactly one
> (I)-frame from its input, and then terminates.
>
> I will make this code available in due course, but I wanted to mention
> it now in case any readers are particularly interested and/or could
> help, especially with the MPEG parsing aspects.
>
> In doing this I have encountered the question of what should happen when
>  an application does not read its input as fast as the MPEG source is
> supplying it.  Mike, what does the driver do in this case?  Is there a
> finite kernel buffer?  If it overruns, is there an error, or is it just
> discarded?
>

The kernel driver has a finite sized buffering capacity.  It's a set 
number of buffers of a particular fixed size.  The low level buffering 
code in pvrusb2-io.c does not determine this, but code which uses that 
module configures itself according.  For read() style streaming in 
pvrusb2-ioread.c, there are two macros at the top of the C file which 
determine this.  Right now it's 32 buffers with each buffer being 16KB in 
size.  The driver cycles the buffers through the USB core as a pipeline, 
keeping as many queued up as possible.  As they each become filled, then 
they are made available to satisfy read() requests.  If the app stops 
reading and the buffers do fill up, then the driver simply stops 
requesting data from the device.  Eventually I believe the device will 
simply start dropping data (and you'll see probably some breakup from the 
missed frames).

   -Mike


-- 
                         |         Mike Isely          |     PGP fingerprint
      Spammers Die!!     |                             | 03 54 43 4D 75 E5 CC 92
                         |   isely @ pobox (dot) com   | 71 16 01 E2 B5 F5 C1 E8
                         |                             |