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

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

 > I'm not sure if that would change anything - unless the budget card delivers
 > a better muxed stream. But then again, it's the same driver, so I guess
 > there would be no difference.
 > 

About muxing:
The problem with the bad muxing is twofold. 
First, there is the problem that the DVB-s card can't put out the
original transport stream. The data you get from the card is taken/snatched
from the buffers of the MPEG decoder. They consist of a video and an
audio buffer and a list of PTSs. The driver waits until the data for
one PTS is complete in the buffer and than copies the data quickly
before the decoder "takes" it away. The data in the video buffer is
pure ES and in the audio buufer its PES. That's why the AV_PES format
has this strange arrangement. 
After that we put the data into PES packets and add some PS
headers. There is not much checking for good muxing possible this way.
The new API requires that TS packets can be read from the dvr device,
so we also generate a TS from the "AV_PES" data. Since we don't know
the original TS the muxing is equally bad.

The second problem is that a well muxed TS can contain PES which, if
written in the order of appearance can be badly muxed in a PS.
Thus, a PS created from a TS recorded from the budget card (remember
the budget card gives you the original TS from the broadcaster) can
still be vadly muxed. That's why the linux dvb api uses TS for the dvr
device, since that is the "natural" format. Everything else has to be
processed which can't always be done in realtime and/or a pipe.
A good example for a bad PS resulting from a good TS is the ARD or ZDF
broadcast. Unfortunately, they are sending video PES that are longer than
65536 bytes (i.e. the maximum length for a PES in PS). This is no
problem in a TS (its allowed in the specs), but if you imagine
something like this:

A1 V1V1V1V1V1 A2 V1V1V1V1V1 A3 V2V2V2V2V2 A4 V2V2V2V2V2
where Ax and Vx are TS packets belonging to the xth PES packet. You
would get following order for the PES.
A1 A2 V1 A3 A4 V2
Now you see that some data of V1 that in the TS came before A2 now
comes after A2. This means its too late and you can get a video buffer
underflow. This could also be the other way around and cause an audio
buffer underflow.
The only way to fix that is to separate the to streams complete
(i.e. demux into ES) and than mux them completely new. The only
information you may be able to use is the starting time of the streams
to get proper av sync. That's what I do in my version of mplex, where
demux the streams, take the starting PTS and then put it into the
muxing routines of the mplex program from bbmpeg.

I hope that clears up the matter.
Since I don't want to type all that again, we should probably put that
into the FAQ.


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.