[vdr] Re: vdr at dbox2

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

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).

> 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_!

> 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.

> 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?

Klaus


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