On Mon, Aug 06, 2007 at 08:44:49PM +0200, Lars Bläser wrote:
> > For the moment, we have only a plugin for vdr and some demo programs to
> > transfer TS/ES data. There's no plan for a DVB adapter-like integration, but
> > there's no obstacle in writing one...
> "only a plugin for vdr"?
> does that mean a output plugin like the one for the dxr3?

Haven't seen that yet, but I guess it's similar. It has methods for playing
ES and TS (see below) and uses the transfer mode.

> does it work with other plugins like the dvd-plugin?

Yes. It also provides the OSD-stuff.

> what about the h.264, vdr does not support that (yet)?

"Our" vdr does already. Due to performance constraints with the Geode,
remux.c was replaced in the RMM-vdr with a more optimized one from the
beginning (but it's still API compatible). That allows some really nasty

Now there's a simple h264 detection added. It's maybe not formally correct
(I'm sure that I've missed some obscure packing scenarios), but it works
with the few h264 channels on air... After the h264 detection, the remux
output is no longer PES, but raw TS. So the CPU load SDTV vs. HDTV is about
the same, no complex repacking is done for h264. The TS recordings have a
synthetic PMT now and then, so they are correctly detected by mplayer/vlc.
The frame index is also stored, ie. go-to and jumps work. The playback
section detects the TS format and forwards it directly via the
TS-play-methods to the card, as the TS demux runs on the DeCypher (load
sharing, quite important with a 300MHz turtle ;-) ).

> > The current scheme works quite fine, also it requires only a small
> > DVB-independent kernel driver for establishing the shared memory
> > communication. BTW, when reading the DVB-ML, I don't get the impression that
> > the DVB subsystem is in a good shape for the near future :-(
> anything better to offer?

No (enough other things to do...), but the idea of putting the tuner parts
into user space is IMO the future. 

> the problem is that this is the only solution for linux with vdr

The old API itself is OK for most aplications. But I don't want to write a
device driver now. I've lost track during all the PLL refactoring and the
totally new API for S2 support is IMO a bit oversized and too preliminary to
rely on for a "product".

The RMM S2 stuff on the RB Lite uses the old 2.6.11 and packs the few
additional S2 parameters in the upper FEC bits. It is a hack, no question,
but it's compatible and an easy patch on "proven" kernels.

         Georg Acher, [EMAIL PROTECTED]         
         "Oh no, not again !" The bowl of petunias          

vdr mailing list

Reply via email to