[linux-dvb] VDR 0.80pre2 - another step towards NAPI

[Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de>]

I have uploaded the current status of VDR with the new API to

  ftp://ftp.cadsoft.de/pub/people/kls/vdr/vdr-0.80pre2.diff.gz

This is a 'diff' between the official VDR version 0.72 and my
current source.

NOTE: in the previous patch I had already introduced a "Dolby PID" and
modified the channels.conf file. Since there are so many other problems at
the moment, vdr-0.80pre2 doesn't write that PID into channels.conf, thus
leaving the format compatible with VDR 0.72. So if you have written a
channels.conf with vdr-0.80pre1, please revert to the file from VDR 0.72.
Sorry for this inconvenience, but I didn't anticipate that adapting VDR
to the new API would cause so many problems...

VDR 0.80pre2 is still pretty far from being stable. In particular, the following
problems exist:

- With the CVS driver dated 2001-04-18 recording works somehow for FTA
  channels. When I record and replay an encrypted channel, the picture and
  sound are heavily distorted.

- With the CVS driver dated 2001-04-28 the video packets are sometimes not
  in sync with the beginning of a new picture, so VDR can't determine the
  frame borders. This results in distortions at the beginning of a recording
  and bad functionality of the "skip +/-60s" and "fast forward/back" functions.
  Since in the past the driver always started a new video packet when a new
  picture began, I hope this will be fixed in the driver.

  So for the moment I suggest using the CVS driver dated 2001-04-18 (don't know
  exactly when between 2001-04-18 and 2001-04-28 this problem was introduced).

- Something must still be wrong in the code in remux.c that implements cTS2PES,
  because when I dump a recorded file with my 'xlist' tool (available in the same
  directory as the above 'diff' file), there are lines like

    703619 00 picture_header - temporal_reference:    0  picture_coding_type: 0

  which indicate that there is a sequence of 0x00 bytes in the file that are
  not supposed to be there. The code for cTS2PES has been taken from the
  'tuxplayer' that comes with the driver, and has been rewritten to suit VDR's
  needs. Maybe I have introduced a bug while doing this, so if somebody could
  take a closer look at this part, I would appreciate that.

- The program still segfaults on occasion, with the backtrace in 'gdb' pointing
  to "poll () from /lib/libc.so.6".

- Since I'm not sure if the way VDR implements the recording function is how
  it is supposed to be, let me sum this up so that somebody with more knowledge
  about this could correct me:

  * cDvbApi::SetChannel() sets the PIDs with DMX_OUT_DECODER when tuning to
    the channel.
  * When a recording is started, cDvbApi::SetPids(true) is called to have
    the PIDs set with DMX_OUT_TS_TAP (haven't found a better way to switch
    on delivery of the TS).
  * The TS is read from /dev/ost/dvr and then run through the cRemux::Process()
    function, which converts the TS into "multiplexed PES" (as is done in the
    'tuxplayer'). See the description in 'remux.c', which explains exactly
    what cRemux::Process() does. I believe here's where the main problem currently
    is - something must be wrong in cTS2PES.
  * The resulting data is written to the 001.vdr, 002.vdr... files.
  * At the end of the recording, cDvbApi::SetPids(false) is called to turn off
    delivery of the TS (is there a better way to do this?).

So, I'm afraid there's still a long way to go until VDR runs stable with the
new driver. Any help in making this stable would be greatly appreciated.

Klaus
-- 
_______________________________________________________________

Klaus Schmidinger                       Phone: +49-8635-6989-10
CadSoft Computer GmbH                   Fax:   +49-8635-6989-40
Hofmark 2                               Email:   kls@cadsoft.de
D-84568 Pleiskirchen, Germany           URL:     www.cadsoft.de
_______________________________________________________________


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