[linux-dvb] Re: [vdr] AC3 over DVB-s is possible - Part2

[Wolfgang Fiesel <fie@iis.fhg.de>]

"Dr. Werner Fink" wrote:

> On Tue, Feb 19, 2002 at 11:13:28AM +0100, Wolfgang Fiesel wrote:
> > Hello,
> >
> > as I promised last week,
> > now AC-3 over Digital Output (SPDIF) for DVB-S is reality (recordings
> > and DVD playback).
> > Of course if the recordings doesn't include any AC-3 data the SDPIF
> > output will be operate like before (raw PCM).
> > I'm using DVB-S version 2.1 (Hauppage)
>
> Fine ... the only question I've: Why the DVB developers have
> said that this wouldn't work.  This because I've supposed this
> a half year ago at the linux-dvb@linuxtv.org list.
>

I think the main problem was here, it need time and money.

>
> > It's time to throw away the soundcard and forget the -a switch.
> > Nevertheless I modified the code very carefully and minimized the
> > patch effort. Therefore all previous AC-3 playmodes (-a switch) should
> > also operate like before.
> >
> > How does it work ?
> > The secret is the IEC 61937 paper which describes the wrapping of AC-3,
> > MP3, DTS, ... into raw 16 bit PCM data. Finally the LPCM
> > transport feature of the DVB driver was the key to realise it.
>
> This is exactly how ac3dec with -C/-P and ac3play it do.
>
> >
> > The patch is related to Klaus latest update version (vdr-0.99) to get a
> > chance
> > to be integrated if the test phase should be successfully. Since two
> > days I've check it by myself with different AC3 recordings and DVD's. Up
>
> Hmmm ... please have a look on send_ipack() in driver/dvb_filter.c
> of the DVB driver 0.9.4.   Maybe it is possible to do the same
> IEC 61937 stuff directly in the DVB driver.  For replay AND
> normal TV viewing.  AFAIS in send_ipack() the mpeg stream will be
> scanned if p->repack_subids is true (by default it is set to
> false at init_ipack()).   Maybe the wrapping of AC-3 into raw 16 bit
> linear PCM could be done at send_ipack() and the resulting PCM
> stream forwarded to SDPIF output as a replacement of the MPEG
> decoded PCM stream.
>

It sounds very interested to do it.
As far as I see the situation of the data path inside the DVB card there are two different
operation modes:

1. I call it direct mode = receive mode:
Here the recieved PS will be filtered. The final Video/Audio stream will be deliverd directly
to the MPEG-2 decoder (Texas Instruments). The audio output is at first available in digital
shape --> direct output of SPDIF and will be directly converted to analog output.
In this operation mode the DVB card is complete independent from any PC bridge activity. I
think there also no driver activity anymore (after initialisation phase).

2. I call it memory mode = playback mode:
Here the PC store it's own PES packets directly into a shared memory location on  the DVB
card. It seems that our wonderful LPCM feature is only possible in this operation mode
because it is not defined in the MPEG-2 system standard. (I'm right ?). In this mode the
driver has to do a lot of things (move the PC data into the right memory location, check
data, configure some HW).

As I understand previous answers from the developers we can't use both operation modes AT THE
SAME TIME.

If we would like to have AC-3 during TV viewing we have to modify the 1. mode
The only programmable part in the DVB card is the ARM processor who is responsible for
demultiplexing the PS data (right?). But how can we (ARM) bypass the TI decoder to access
directly the digital output ?
I believe here is the critical point. This solution is probably impossible. To reveive the
AC-3 packet we have to switch into the receive mode (1) and at the same time the driver has
to write back the wrapped AC-3 stream by using the playback mode (2).

But nevertheless I'll try to understand the driver philosophy and the background of the DVB
card data flow more in detail.

Wolfi





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