[linux-dvb] Re: mplex loses sound

[Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de>]

"Marcus O.C. Metzler" wrote:
> 
> Klaus Schmidinger writes:
>  > I just tried to remux a recording I made a few days ago
>  > (and which had some audio glitches). So I did
>  >
>  >   mplex -t MPEG2 -o 001.vdr 001.vdr.x
>  >
>  > where '001.vdr.x' was my original recording. The resulting
>  > file started to replay just fine, but after about one minute
>  > the audio suddenly disappeared and never came back, even if I
>  > fast-forwarded all the way through the recording.
>  >
>  > The same thing happens if I replay the recording with 'cat',
>  > which rules out a problem in VDR.
>  >
>  > Could this be a bug in 'mplex'?
>  >
>  > Klaus
> If the input file has a real audio glitch, i.e. an error that comes
> from bad reception, mplex cannot multiplex the streams.

Well, I guess then that pretty much makes the use of mplex obsolete,
doesn't it? My original recording was fine almost entirely, especialy
there was no audio problem at the point where the mplex'ed file lost
audio. After running it through mplex I lost almost all of the audio
(not that this is an especially valuable recording, though). I'd say
if there is a real glitch in the data stream, a program like mplex
should take every effort to produce a correct output as soon as possible
after the glitch (naturally, it can't repair the glitch itself, since
there might be a major amount of data missing).

Of course I'm aware that mplex is still work in progress, so this is not
criticism, just some thoughts ;-)

> Have a look at
> the results from the audio stream analysis. If there are only a few
> frames than mplex stumbled over a currupt frame. The easiets way to
> test if the audio stream is corrupted, is to use es_demux to get the
> audio ES and then use mpg123 to test, if the audio stream is ok.
> 
> If the audio stream is not corrupted tell me, because then I have some
> work to do.

Here's what I get from es_demux:

kls@video:/video/nano/2001-02-27.18:28.10.05.rec > ~/vdr/DVB/apps/mpegtools/es_demux 001.vdr.x x.x x.y
Reading 001.vdr.x
Opening x.x for audio
Opening x.y for video
VPTS - APTS = 0.2854s

I don't know if this was a stupid thing to do, but when I did

  cat x.x > /dev/video0

(where x.x was the file from the es_demux call) the TV screen went black (no
sound) and my machine totally locked up (interestingly it could still be ping'ed
from another computer, but that's all). I had to do a reset to get it up and
running again. Maybe the driver locks up when it receives certain unsuitable
data? Well, whatever one sends to the driver, it should never lock up the
entire system.

If you'd like to take a look at the audio file produced by es_demux, I could
make it available on our server. It is about 23 MB in size, but I guess the problematic
area should be within the first few MBs, so I guess it would suffice if I
upload, say, 2MB. Please let me know.

Klaus
-- 
_______________________________________________________________

Klaus Schmidinger                       Phone: +49-8635-6989-10
CadSoft Computer GmbH                   Fax:   +49-8635-6989-40
Hofmark 2                               Email:   kls@cadsoft.de
D-84568 Pleiskirchen, Germany           URL:     www.cadsoft.de
_______________________________________________________________


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