[linux-dvb] Re: converting PES to TS while reading from (multiple)/dev/ost/demux0

[<mocm@metzlerbros.de>]

Since we are changeing some things on the driver and API layout anyway
(see NEWSTRUCT branch in CVS) it might be good to collect some input
about what is needed and for what it is needed. You also have to bear
in mind that some changes that may be desirable won't be possible for
all the different hardware implemetations, so that it has to be seen
if a software implementation in the driver is reasonable or if a
userspace implementation is better suited.

Felix Domke writes:
 > > Which is AFAIK a rather nasty limitation of the current API.
 > > As far as I know there is no way to find out where exactly
 > > payload_unit_start_indicator bits were set when you read from
 > > a demux device. You need to read TS packets from dvr if you want
 > > to have the payload_unit_start_indicator bits. But dvr
 > > only supports one concurrent opener...
 > It *IS* a nasty limitation.
 > 
 > I would prefer:
 > 
 > DMX_SET_PES_FILTER
 > 
 > with two new options:
 > 
 > a.) type, like "TRANSPORT" (all 188 bytes), "PAYLOAD" (like the deafault)
 > and maybe a "read one payload unit as once", maybe with a header (with the
 > size and - maybe - things like the adaption field, but maybe this is exactly
 > what AV_PES did.. i don't know. so maybe just "PAYLOAD" and if you want to
 > get the PUSI-flag "TRANSPORT")
 > b.) the estimated datarate, or more low-level, the amount of data which
 > should be available until an interrupt occurs.
 > 
 > The absence of b.) leads to high system load if you break up a fast stream
 > (Video/Audio, EIT) into many small packets, or, if you use a big "buffer
 > size" (or "interrupt threshold") to the problem that you cannot read ONE
 > small packet (for low datarate streams, like PAT/PMT or even NIT).
 > 
 > A huge company did a nice api for using their chipset with Linux, it very
 > much like the OST-Api, but has this new options. I really miss them in the
 > OST.

It may be reasonable to implement a PES demux in such a way that it
will wait for a full PES before it can be read. This presents 2
problems. You will most likely lose the correct muxing of audio and
video PES and you don't know how long the video PES can get.

Concerning multiple opens of the dvr device I would say it doesn't
make sense. If you need more than one application to receive the data,
you can handle that in user space. But, since I don't know what people
would like to do with the data, it would help everybody to understand
it better if they explained that when they suggest changes of the API.

Marcus



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