[vdr] Re: vdr at dbox2

[Andreas Oberritter <obi@linuxtv.org>]

Am Sa, den 28.02.2004 schrieb Klaus Schmidinger um 10:26:
> Andreas Oberritter wrote:
> > 
> > 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.
> 
> It might help if VDR sends the video and audio data into separate devices,
> which I would be willing to change. Currently it sends both data streams
> into /dev/dvb/adapterN/video0, which is ok for the LinuxDVB driver (with the
> av7110).

This is an improvement of the current situation (Carsten already
modified VDR to do that), but it won't reduce the risk of audio buffer
underruns caused by too large video packets.

> > 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.
> 
> This is definitely not going to happen. TS is not a format for _recording_,
> it's a format for _broadcasting_!

We're abusing DVB receivers and not using DVD players after all. TS is
their mother tongue.

> > 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.
> 
> Well, PES is the recommended format for _storing_ recordings, so I'd say
> they should get this to work. Recording TS is surely not the best way to
> go.

PES is quite useless when multiple PES are stored inside one file
without meta data. PS is the recommended format for storage.

> > 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.
> 
> But in the end the player still needs to assemble the complete video and
> audio frames, so I don't see the problem here - it _must_ have enough
> memory for this - or am I missing something here?

No, you just write the TS into dvr0. It will appear to the dvb api as a
regular stream. You can set up PAT/PMT/EIT filters etc just as in live
TV mode. The hardware driver then decides what to do with those packets
for which a DMX_OUT_DECODER filter exists. The MPEG decoder (not the
demux!) of the dbox2 can handle TS natively for example. Other drivers
might prefer to feed the TS into the demux or to extract the payload in
software and write it to the a/v buffers. That's completely transparent
to the userspace application.

Regards,
Andreas



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