[linux-dvb] Re: V4 API proposal

[Rob.McConnell@Zarlink.Com]

HI Folks,

Just a few comments to make as well.

1. I agree that removing the dvrX device is best.  The Linux s/w I
currently use to control my demux device allows you to write to it and this
would keep things consistent.

2. This arrangement is completely suitable to my current h/w config (i.e.
multiple TS inputs to a single demux h/w device = separate logical demux
devices each sharing a common pool of h/w pids).

4. Good - multiple PID filters per FD match my h/w requirements for
recording to HDD.

5.  Output control.  I think we need to have another look at this again.
When setting up a PID filter what type of output should be delivered to the
internal queue?  My h/w supports the following types in addition to the
dedicated A/V decoder streams (DMX_OUT_DECODER):

      a) Full 188 bytes TS packets - yup, this is the same as setting the
output to DMX_OUT_TS_TAP.
      b) Header and adaptation fields only - useful for interrogating
fields without having to have the full payload dumped into memory and
copied
                about endless times.
      c) Just the payload.
      d) table sections with our without filtering.
      e) The h/w also supports a "dump" queue that can be configured to
allow parts of a TS from other PIDs to be dumped into it.  For example,
                 it is possible to configure the h/w so that the payload
goes off to one queue and the header/adaptation fields are delivered to
this
                 general dump queue.

6. Another device to support PSs for MPEG-1 and MPEG-2 formats would be
desirable and should be implemented in kernel space to take any advantages
of the available h/w.   For devices that don't have a h/w filter for the
stream id/etc. then this should be implemented in s/w (kernel space) to
keep the api consistent.  For PS material this is likely to be from a HDD,
CDROM, DVD, ... that should have DMA capability, so it would make sense to
keep it all in kernel space with ioctls to choose the filtering capability
and to read the filtered PS back.

For PES/ESs, the h/w that I am in contact with allows a "clip-mode" region
to be defined to allow playback of A/V streams.  This buffer in memory is
then a direct feed to the associated audio and video decoders.  I guess
this would be implemented by writing to the audio and video devices
directly.  What about handling of DMA from a HDD instead of having to use
the write syscall?  What about mmaping instead to speed things up?

Do we currently support Audio ES in the API?   If not, then this needs to
be added as my h/w supports this.

That's all 4 now,

Rob ;-)




                                                                                                                                       
                      "Florian                                                                                                         
                      Schirmer"                To:       <linux-dvb@linuxtv.org>                                                       
                      <jolt@tuxbox.org>        cc:                                                                                     
                      Sent by:                 Subject:  [linux-dvb] V4 API proposal                                                   
                      linux-dvb-bounce@                                                                                                
                      linuxtv.org                                                                                                      
                                                                                                                                       
                                                                                                                                       
                      06-Mar-2003 11:30                                                                                                
                      PM                                                                                                               
                                                                                                                                       
                                                                                                                                       




Hi,

after talking to Johannes Stezenbach i felt it is time to update the API
proposal:

1. /dev/dvb/adapterX/dvrX:

The dvrX devices will be removed. There is no need for them and no one
really likes them :D

2. /dev/dvb/adapterX/demuxX:

A) Instead of writing TS data to the dvrX device you are now allowed to
write TS data to the demuxX device.
B) Before writing TS to it you'll have to call an ioctl to put the demux
device into memory mode. (DMX_SET_SOURCE)
C) The hardware demux has to export a logical demuxX device for _each_ hw
input channel it supports (e.g. if the hw supports 2 frontend and 1 memory
based input it will export demux0,demux1,demux2). It is up to the user to
map these logical devices to hw inputs (via DMX_SET_SOURCE)
D) We'll provide an ioctl to query the demux in which mode it currently
operates / which modes are supported (DMX_GET_SOURCE,DMX_GET_SOURCES)

3. Memory based dummy fe (FE_MEM)

Only real (hardware) fe's will be supported. There is no need for a dummy
fe. (demuxX will do)

4. Multiple filters per FD

Multiple filters per FD will be supported through
DXM_ADD_FILTER/DMX_DEL_FILTER ioctls. We did not decide yet wether we

A) allow just a single pid per call
B) allow multiple pids per call
C) require multiple pids to be set in a single call

5. Output control (TAP, decoder, HDD)

Yet another item which needs some pro/cons discussions.

6. Playback of non TS data (PES, AVPES, ...)

You are only allowed to write TS data to the demux. All other data has to
be
written to the a/v decoder (if availible). We probably need to design a
second api/filter layer to support all different kinds of a/v data. I
propose creating a new device (e.g. avdecoderX) and combine the existing
audioX/videoX with the new filter api. Needs some discussion too. Low
priority. Maybe V5 item?

Suggestions? Objections? Expect another update in a couple of days.

Thanks,
   Florian




--
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe
linux-dvb" as subject.








-- 
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe linux-dvb" as subject.