[linux-dvb] Re: no more glitches - pity but not :-(

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

Guido Fiala writes:
 > >Guido Fiala wrote:
 > >> It seems that with dvb 0.81 vdr 0.7 and going to PES has finally
 > >> eliminated the recording glitches and audio problem for me!
 > >>
 > >> At least so far i did'nt observe it anymore, great.
 > >
 > >Which channels did you check?
 > >Have you for instance tried ARD, ZDF, 3sat?
 > 
 > Ok, you are right with ARD i could reproduce it instantly, but at
 > least i have no longer glitches with Pro7,Sat1,Vox.
 > (That is no flash-frames & audio-latency)
 > 
 > But still at all channels the frame-skipping problem.
 > (Are these frames not in the recorded stream or are they just
 > not played? If they were'nt recorded - were got they lost?)

The Frames are all there. Unfortunately, the Hardware configuartion of
the card forces one to use methods to extract the stream data, which
result in badly muxed streams. So that any audio glitch is a audio
buffer underrun and any video glitch is a video buffer underrun.
You can fix the files, if you use a remuxer. I just added a version of
mplex (from the bbmpeg package) to the mpegtools directory on the CVS
server. I adjusted the program for linux and added a demuxer, so that
you can call the program with just the muxed MPEG file you get from
the card. Take a look at mplex --help for the muxing options. In the
case of a file from the card use mplex -t MPEG2.
If there are any problems, please tell me. I haven't tested it much.

 > 
 > I wonder - can it be a problem with the encoding side, 
 > that the broadcasters doesn't conform to the standard?

The problem is that transport stream muxing can be done differently
from program stream muxing. So that the PES you extract from a
transport stream are not muxed correctly.

.E.g

transport stream:

APES1.1 VPES1.1 VPES1.1 VPES1.2 VPES1.2 APES1.3 VPES1.4 APES2.1
APES2.1  VPES1.5 

program stream:

APES1 APES2 VPES1

where APES1 is audio PES packet 1 with the parts in APES1.1 - APES1.2
and the same for video. In this simple non realistic example, you
could get a video underrun, because the second audio PES in the program
stream is written before the first video PES.
We don't get any information about the TS packet order from the card,
so we can't put out the packets in the correct order. And remuxing in
the driver is at the moment not possible, at least not in an efficient
way. Just look at mplex and the time and resources it uses.

I hope that helps everybody to understand the problem.

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.