Re: remote DVB watching ?

["Ralph Metzler <" <rjkm@netcologne.de>]

Carsten Koch writes:
 > > > > what about getting real mpeg2 output right out of the card?
 > > > That would definitely be the best solution.
 > > > I do not think there is any need for the PVA format at all.
 > > 
 > > Afaik it is a firmware restriction, so it is the only way right now
 > > until Technotrend changes their firmware.
 > 
 > I thought convergence has source for the firmware?
 > Would it not be possible to repair the firmware so
 > it outputs proper MPEG?
 > If not, would it not at least be possible to repair
 > the firmware so the data sent by it would it make 
 > easier for the driver to convert it to proper MPEG?
 > 
 > In any event I think it is a bad idea to see a proprietary
 > data format at any place outside the driver.
 > 
 > I believe even Technotrend has realized that - in spite
 > of the fact that they were the ones who made that design
 > mistake in the first place. That's why they wrote the
 > external converter. It would be nice if Linux were smarter
 > and would not expose the PVA format at all.

We are working on that and I hope that the next version of the driver
will not externally deal with PVA files anymore (besides backwards
compatibility for playback).

To make it a little clearer what is going on I will explain in a little
more detail what goes on and what the problems are.
Since the data sheet is public now I am not telling anything secret.

The DVB card does not provide any direct access to the transport
stream. There is a so called "high speed data interface" on the
TMS320AV7110 where selected TS packets could be sent to other hardware
but this is not used on the card. Other hardware using the AV7110
might be using it.

The firmware (or rather the "ARM application" which is loaded at driver
installation time, the actual firmware of the AV7110 is in on-chip ROM)
only has access to the actual payload of the TS, i.e. either sections
or PES. The adaptation field cannot be accessed
(actually the private data field can be but not the others containing the
PCR). So, the full timing information is not available to the 
ARM application, only to the MPEG2 decoder.

Recording/Playback is implemented by directly reading/writing the 
data from/to the internal buffers of the MPEG2 decoder 
The decoder keeps video as ES plus a PTS buffer and audio as PES
packets.
Concerning the PVA or AV_PES format:
The interface between AV7110 and SAA71146 is a dual ported 8KB RAM of 
which 6KB are usually used for data transfers. 
Now, if you have a video ES stream which can be longer than 6KB
between new PTS values, how do you push them through a 6KB buffer? 
You write X<=6KB bytes at a time and add a header which specifies X,
maybe some flags which tell if it is video or audio and when a PTS
comes and a mechanism to get 4 byte alignment (DMA transfers of the 
SAA7146 are 4 byte aligned).
Add "AV" at the start and a continuity counter and you have a PVA
file which can be fed right back through the dual ported RAM to the
card for playback.
Itīs really the simplest format which accomplishes all this.

So, now you are stuck with video ES+PTS and audio PES.
If you know a good way to reconstruct the PCR from just the PTS of those
2 streams and make a complete transport or program stream out of them
please let me know.
Producing a PES stream (only video + audio PES, no program headers)
which can be played back with the DVB card is no problem. 
We might use this or a transport stream without PCR in the adaptation
field as the next step in development.
But this stream wonīt work with most other software or hardware DVD players.

Ralph