DVB playback: audio loss, memory leak
Posted: 30 Sep 2009 15:47
My goal is to live transcode a DVB-S channel and stream it to a Wowza server via rtp.
Basically it works, but after some time (in the range of hours) there's no audio.
Trying to track the issue down I used this cmdline:
That means, the transcoded steram is at the same time playbacked locally, written to HDD and streamed to another machine.
I started the process yesterday, when I checked today, there was nomore audio playing.
I am trying to understand at which point audio is lost. Findings up to now:
- when checking the recorded file, audio is ok, plays to the end w/o sync loss. That means DVB input and transcoding are ok.
- the recording process lost audio at some point (dst=display)
- the remote server forwards the stream. When connecting to this stream, there also is no audio after some time
I don't know how vlc internally works (especially the duplicate module). But it seems clear to me that the input and transcoding part are ok. What I can't understand is how it's possible that the display module and the rtp module lose audio, while the access module (write to file) has audio ok.
1 possibility is that the transcoding produces a stream which at certain points vlc itself can't handle. I didn't yet check to playback the recorded stream in full length from beginning to end, I just checked if there is still audio at the end.
I'm using vlc 1.02 on SuSE Linux 11.0. Some months ago I tested the same with vlc 0.98 (not 100% sure about the version) with the same result.
Memory leak:
I also observed that after starting it with this cmdline, the vlc process takes about 100 MB of memory. That slowly gets more and more, after 24h it takes ~700 MB. That means I can run it only for ~2 days on my machine before having to restart vlc. Not sure if that's related to the audio issue.
When running with -v parameter, I get lot of debug output, most related to stream timing (pts, discontinuity, late buffer for mux input, late picture skipped, decoder synchro warning, PTS out of range, buffer in advance, ...).
Of course I could define a set of test cases to get further conclusions. But that's very time consuming since it takes hours for the problem to show.
That's why I post this here, hoping somebody with more experience and/or insight reads it.
Basically it works, but after some time (in the range of hours) there's no audio.
Trying to track the issue down I used this cmdline:
Code: Select all
vlc -v dvb:// :dvb-adapter=0 :dvb-satno=2 :dvb-frequency=12557000 :dvb-srate=2156000 :program=1 :dvb-caching=3000 :dvb-voltage=13 --sout "#transcode{vcodec=h264,vb=400,scale=1,deinterlace,acodec=mp4a,ab=64,channels=2}:duplicate{dst=display,dst=std{access=file,dst=/store/tmp/CH1.ts},dst=rtp{dst=192.168.0.215,sdp=file:///server/DH2/CH1.sdp}}"
I started the process yesterday, when I checked today, there was nomore audio playing.
I am trying to understand at which point audio is lost. Findings up to now:
- when checking the recorded file, audio is ok, plays to the end w/o sync loss. That means DVB input and transcoding are ok.
- the recording process lost audio at some point (dst=display)
- the remote server forwards the stream. When connecting to this stream, there also is no audio after some time
I don't know how vlc internally works (especially the duplicate module). But it seems clear to me that the input and transcoding part are ok. What I can't understand is how it's possible that the display module and the rtp module lose audio, while the access module (write to file) has audio ok.
1 possibility is that the transcoding produces a stream which at certain points vlc itself can't handle. I didn't yet check to playback the recorded stream in full length from beginning to end, I just checked if there is still audio at the end.
I'm using vlc 1.02 on SuSE Linux 11.0. Some months ago I tested the same with vlc 0.98 (not 100% sure about the version) with the same result.
Memory leak:
I also observed that after starting it with this cmdline, the vlc process takes about 100 MB of memory. That slowly gets more and more, after 24h it takes ~700 MB. That means I can run it only for ~2 days on my machine before having to restart vlc. Not sure if that's related to the audio issue.
When running with -v parameter, I get lot of debug output, most related to stream timing (pts, discontinuity, late buffer for mux input, late picture skipped, decoder synchro warning, PTS out of range, buffer in advance, ...).
Of course I could define a set of test cases to get further conclusions. But that's very time consuming since it takes hours for the problem to show.
That's why I post this here, hoping somebody with more experience and/or insight reads it.