[linux-dvb] Re: Using a low-budget card as a secondary card.

[Ralph Metzler <rjkm@convergence.de>]

Klaus Schmidinger writes:
 > "Marcus O.C. Metzler" wrote:
 > > 
 > > Klaus Schmidinger writes:
 > > 
 > >  > VDR will do the recording just like shown in the DVB/apps/test/test_pes.c
 > >  > example. If that is also possible with the budget card, then it will work.
 > >  > The data will be stored as multiplexed PS/PES, just like in VDR
 > >  > version 0.7x.
 > > 
 > > Be careful , a video PES in a TS usually doesn't contain the length
 > > field, i.e. it is set to 0. Furthermore, their length is not bound by
 > > the maximal possible value for an unsigned  16 bit number,
 > > i.e. 0xffff. ARD and ZDF are masters in very long video PES, this is
 > > part of the reason for the muxing problem. Unfortunately, this is all
 > > conform with the MPEG standard.
 > > 
 > > Marcus
 > 
 > So, what exactly am I supposed to do?
 > The NAPI delivers video and audio as two separate data streams.
 > I want to store them in ONE file as a multiplexed PS/PES stream,
 > just like the 0.8.2 driver did when reading from /dev/video.
 > I am also thinking about storing the AC3 digital audio data as
 > a second audio stream in that file. Do you think this will be
 > feasible? When replaying, VDR would then filter out the second audio
 > stream and send it to whatever code or program necessary to play
 > the AC3 sound. The video and "normal" audio data would be sent into
 > /dev/ost/video as usual.
 > 
 > Isn't there some "standard" that says how a multiplexed PS/PES stream
 > has to be created in order to be replayed without problems? If the
 > "very long video PES" blocks are conform with the MPEG standard,
 > why is it so hard to handle them?


With the AV7110 card it is hard to handle them because of the way the video
ES is extracted from the decoder buffer. There is a queue with PTS and
length entries in the hardware. Reading of data can only be done when
the queue pointer jumps to the next slot (when the next PTS comes)
because before that the length entry of the current slot is not right yet.
So, if the video PES is very long (which means the time between PTSs
can be even longer), those video PES are sent very late compared to 
the audio PES and muxing will be even worse than with other channels.
If you build real-time remuxing into VDR this will of course be no
problem at all :-)


Ralph




 


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