Mailing List archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[vdr] Re: vdr at dbox2
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.
Home |
Main Index |
Thread Index