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

[Marcus O.C. Metzler <mocm@convergence.de>]

Klaus Schmidinger writes:
 > Ralph Metzler wrote:
 > > 
 > >  > 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 :-)
 > 
 > That's exactly what I am going to do.
 > 
 > What would help here would be some "official" standard text
 > that describes how exactly two separate video and audio streams
 > are to be multiplexed. So far it appears to me like remultiplexing
 > is some sort of "black magic"... ;-)
 > 
 > Is there any document that I could consult regarding this?
 > 
 > Klaus

The only thing I found is the source code of mplex, i.e. the muxing
part of bbmpeg, which I used for the mplex program in the mpegtools.
As far as I can understand the code, they use a "faked" buffer that
represents the buffer of the player. they "write" the PES data into
the buffer according to the PTS and check if the PTS is less than the
SCR which they also simulate. Then they use some coditions depending
on buffer filling and PTS of audio and video to write into the buffer
and read out of buffer, i.e. write to disk. They only rule you can
make out of this is that you have to have the data out of the buffer
before it needs to be displayed, i.e. PTS < SCR. The audio and video
buffer size acts are the boundary conditions for that. I didn't have
time to take all that stuff apart, so I just used it as is.
Maybe theres is a scientific paper or maybe a some kind of thesis
about that on the net.

Marcus

---------------------------------------------------------------------
Dr. Marcus Metzler                             
mocm@netcologne.de                     http://www.metzlerbros.de
mocm@convergence.de                    http://www.convergence.de

Convergence Integrated Media GmbH          
Rosenthaler Str. 51                   
D-10178 Berlin                             
---------------------------------------------------------------------


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