[linux-dvb] Re: Linux DVB API 4 Q's

[Johannes Stezenbach <js@convergence.de>]

Hi,

Rob.McConnell@Zarlink.Com wrote:
> 
> Seen that there is work being done on the V4 API now.  Does this mean that
> it is full speed ahead on V4 now, or are there other loose ends to fixup
> first?

There was some (little) discussion in private mail, and then
I read through the postings on this subject in the list archive
from around march, and tried to summarize the result.

My plan is to fix the API "real soon now", after a new round of
discussion on the list, and start implementing it. I wanted to
announce my changes on Monday since I'm offline during the weekend ;)

There are lot's of FIXME's in the headers which need to be addressed.

> Have a few Q's about the header files in the V4 API dir in CVS:
> 
> 1: I see that the "dvb_dmx_source_format" has a new format called PES.  Is
> this to cover proprietary formats such as AVPES?

No, we don't care about AVPES anymore. That's left for userspace.
PES means a stream of video + audio (and maybe other) PES packets
without (PS) pack structure. I'm not sure if that's really needed
but someone wants it.

> 2:  Shouldn't the structure "dvb_dmx_source" be:
> 5. struct "dvb_video_source" should be:
> 6. Same for "dvb_audio_source"

Fixed in CVS. Thanks!

> 3:  For the DVB_DMX_SET_PID_FILTER  syscall option 2 (not using the add/del
> pid IOCTLs), if we set all the PIDs up at once then they would all have to
> have the same type, output format and share the same flags.  Now the same
> type and output format are OK, but if you want to prioritise one PID over
> another using the HIGH/LOW priority flags, then this becomes a problem.
> Basically, if you wanted to have different flag values for the PIDs then
> having this single IOCTL to set all the PIDs at once would be a problem.  I
> can see that it certainly simplifies the overall code, but I would favour
> having the ADD/DEL IOCTLs instead as this gives more flexibility to the
> user programs.

Hm, so there's a difference of per-PID flags and per-file descriptor
flags. I'm open for both solutions (i.e. SET vs. ADD/DEL), but I think
SET might be simpler to implement and use. We could have something like:

  struct pid_flags {
	  uint16_t pid;
	  uint16_t flags;
  };
  struct dvb_dmx_pid_filter {
	  ...
	  struct pid_flags pids[MAX_NUM_PIDS];
	  ...
	  int flags;
  };

> 4. Why have the filter id elements of the structs "dvb_dmx_pid_filter",
> "dvb_dmx_section_filter" and "dvb_dmx_sid_filter" been removed?  How do you
> go about removing/changing an already instantiated section filter/sid
> filter without the id field?

Simplification.
I thought they are not needed for PID and SID filters (the PID/SID is the id).
For section and sid filters, I think *I* don't need multiple filters per file
descriptor. If you really want them, protest load enough ;-)

> 7.  For audio decoding, will there be status information for Dolby
> Digital/DTS/.....  returned to user-space?  For example, will the source
> format (e.g. 3/2) be returned as well as whether the program is surround
> encoded (Dolby Pro Logic).  Will there be an IOCTL to select Dolby Pro
> Logic decoding from a multi-channel source?  There are endless options for
> audio decoding, so what stance are we to take with the user/kernel space
> divide?

Audio is difficult, because I don't have a clue. We (== Convergence)
currently do mixing via a simple OSS device, and I thought about the
possibility of using parts of ALSA for more complex audio post
processing options.

If we could create an API which works for all of us I would like to include
it in the DVB API.

 
> 8. What is the current state of the V4 API in terms of available software?
> Is the intention to take the existing V3 API s/w and apply the required
> changes to make it V4 compatible, or are we going to start from scratching
> implementing it.  IMHO, taking existing good s/w such as the section
> filtering and re-writing some of the other demux s/w that was inherited
> from collaboration with Nokia would be the best approach (as we have all
> learnt a lot more about DTV over the years and the existing s/w certainly
> has limitations).

My plan is to port the saa7146 based drivers (and our proprietary cruft)
starting from the existing code. I have no plans to start from scratch.
I also haven't spent any time thinking about backwards compatibility
for exisiting applications. Since the current API is in linux-2.6 we'll
might have to do something. For embedded this is nothing to worry about.

Thanks for your comments!


Have a nice weekend,
Johannes


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