[linux-dvb] AW: Re: API changes (was: C/A routing Question)

["Florian Schirmer" <jolt@tuxbox.org>]

Hi,

>I thought about it for a while. To me the multi-PID demux filter looks just
as 
>good as the dvr design. State handling in the demux device driver might be
a 
>little more complicated, e.g. it's only allowed for DMX_OUT_TS_TAP. (It
could 
>work for DMX_OUT_TAP to get AVPES, but there are some difficulties with
buffer 
>management due to the unbound video PES length.)

A) dvr vs. Multi pid

The dvr design can only support one concurrent user/service. If you want to
record a tv station into a single TS muxed file you open a filter for audio
and video and end up in reading a TS stream out of dvr0. Thats good.

Now lets say you have a transponder with 4 different TV channels and you
want to record that 4 complete TV stations (video+audio+subtile maybe epg or
CAT/ECM or what ever too). How do you do that? The only chance you have is
to open a filter for each pid of each service of each station. You will end
up in lots of streams you have to multiplex later again.

With the multi filter design you will and up with 4 different demux file
handels which each provides a muxed stream with all services of the tv
station. No matter how many services/users are involved. Basically it moves
the dvr design into the demux.

B) Writing PS/AVPES

IMHO you simply can't and shouldn't do that. Writing anything else except TS
to the demux doesn't make any sense to me. What do you expect the demux to
do with PES? The only job of the demux is to route / demultiplex / convert
TS into someting else (different queues, PES, sections, ...)

If you write non-TS data the only reason could be playback. So it is a lot
more straight forward to write that data directly to the decoder. And that
is excatly what /dev/dvb/adapter0/{audio0,video0} are for. Lets keep the
demux TS only.

I know there is hw that cant write data directly to the decoder. (Dbox2
suffers excatly from that flaw). But that could and should be handled by the
device drivers.

>About backward compatibility:
>- input handling for playback is proposed to change, from /dev/.../dvr to
>  a /dev/.../frontend of type FE_MEMORY

Yes for TS playback lets use a FE dummy and disallow writing to the demux.
For non TS see above.

>- I would like to remove the input field of struct dmx_pes_filter_params
>  in favour of the DMX_SET_SOURCE ioctl

Yes, we need to ability to select from which fe the data is allowed to come
from. IOCTL or extend filter params (see below). Dunno what makes more
sense.

>- we need PS (and maybe AVPES) playback; details are not clear yet,
>  but I think this means adding the capability to filter on the
>  PS stream id, and adding a corresponding field to struct dmx_caps

See above.

>In a system with more than one MPEG decoder DMX_OUT_DECODER is not enough. 
>It will be necessary to specify which decoder. I think that the video and 
>audio decoder API should have *_SET_SOURCE ioctls that connect them to the 
>appropriate demux.
>
>This would cause some breakage already. If you have ideas how to avoid
them, 
>please let us know.

For multi filter support we need new IOCTLS. We can change filter settings
for them:

Pid 
Format (TS, Section, PES, PES_HDR, ...)
Source (HW FE1, HW FE2, MEM FE)
Dest (VIDEO_DECODER1, VIDEO_DECODER2, AUDIO_DECODER1, ...)

If we keep the old filter interface for a while we will break nothing.

>> For the PES/PTS/Subtitle problem i would suggest the following: Lets 
>> extent the demux interface to deliver PES headers only. Adding 
>> DMX_OUT_PES_HDR_TAP or someting like this. Should be easy to implement 
>> (if hw supports it) and doesnt break anyting. (Hopefully :)

>Hm, I don't get it. For DVB subtitles you need full PES packages for
decoding. 
>For synchronization you need the STC on demand or set an event (comparable
to 
>gettimeofday(2) or setitimer(2)).

Maybe i'm wrong. Dunno. Lets try: You open a PES filter for subtitle pid.
You open another filter (PES_HDR) on the video (or if different PCR) pid.
>From the video/pcr pes headers you can extract the timecode required to sync
the subtitle data. As i said: could be complete crap ;)

>For video one needs ES headers for size/aspect ratio &c. These are
extracted 
>by the MPEG decoder. No demux business.

? Cant you simply query the decoder?

Bye,
   Florian




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