[vdr] Re: vdr at dbox2

[Andreas Oberritter <obi@linuxtv.org>]

On Wed, 2004-02-25 at 10:08, Carsten Koch wrote:
> What I did not know was, that "vdr works on the dbox2" only means you
> can start vdr and use it for zapping (which you can already do under
> neutrino). In particular, Alexander's VDR cannot play back NFS-mounted
> VDR recordings, which is the main purpose I had in mind.

VDR uses a non-standard format for recording which can not be played on
any hardware other than the av7110 based cards. You need to demux it in
software and feed every single packet into the corresponding demux
output queue.

The best solution for VDR recordings is to convert the stream into a
single program transport stream which can be fed through a single output
queue to the decoder.

The best solution for everything else is to store the TS as it is
received and never modify it. Maybe the softdevice or softmpeg plugins
will help to leave the proprietary av7110 world and convince someone to
modify VDR to use TS as the primary recording format.

While TS playback has been tested quite well with Neutrino (and Enigma
now, too), PES playback using audio0 and video0 has not. Keeping the
stuff in sync is very hard.

The video queue for example is a 64kb ringbuffer. Video PES packets can
be that large, too. Thelength field is set to zero in most video
streams, which means that the packet is of unspecified size. If you try
to write a large video packet at once or try to write multiple video
packets immediately following each other then the audio queue will
underrun because your application blocks waiting for the video queue to
become less filled up.

This will never happen with a properly muxed TS where audio and video
pes packets can be transmitted "simultaneously" because of the small and
fixed TS packet size.

1) Some VDR recordings play back just fine - for a while.
>     I have watched some VDR recordings without problems for a while.
>     After ~15 or 20 minutes of playback, the playback starts to
>     have glitches. Stopping and re-starting playback sometimes
>     helps, sometimes only rebooting the dbox helps.
>     Reminds me of the old days when you had to reload the DVB driver
>     for VDR to work properly.  ;-)

Streams received by DVB hardware do have a known bandwidth and pcr
information can be used by the receiver to synchronize its clock to the
transmitter's clock. Streams played back locally don't have this
information and are played back "as is", i.e. buffers usually fill up
too fast. Dirty hacks are required to manually set the decoder's STC to
a value which makes it try to synchronize a/v. The dbox2 drivers do this
once after AUDIO_PLAY. You could try to set up a kernel timer which
tries that regulary, but I think this won't help if the input stream is
not ok.

> 2) Some VDR recordings crashed VDR immediately with a segfault.
>     I tried running VDR under gdb, but gdb crashes on startup. :-(
>     I tried getting a core file, but the busybox shell does not
>     seem to support that feature. :-(

Gdb needs too much memory. Use gdbserver:
https://tuxbox.org/forum/viewtopic.php?t=22195

> 3) The DVB driver on the dbox does not provide the necessary functions
>     for any of the trick modes (Fast Forward, Fast Reverse, Slow Motion).

They never will for two reasons:
a) The decoder does not support either of these features.
b) The network interface is too slow for real fast forward.

> 4) After a +- one minute skip, very often playback does not
>     resume properly. Stopping and restarting playback with the
>     blue button sometimes helps.

Have a look at the neutrino sources.

>    I will offer my current version of the patch to the tuxbox folks.

Thanks.

Regards,
Andreas



-- 
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe vdr" as subject.