Audio breakup's on 720p channels.

[sirwio]

In sweden two channels SVT1 HD and SVT2 HD broadcast in 720p. While watching live broadcast using the vompclient-marten 2013-03-16 (and using previous builds as well) we do observe some micro audio stutter and some not so frequent longer audio breakups. The audio breakups can be as long as a few seconds!

I have uploaded a 1:28 long recording where while watching there was a long audio break at 1:12. During playback using vompclient-raspi or streamdev (to vlc) the playback breaks at 1:12. But if playback is done directly using vlc it plays fine to completion (without audio stutter) as is also the case using playback with vdr-softhddevice.

The recording, 116MB, can be downloaded from here.
http://ubuntuone.com/4nvxpjRVgqSHxruSao2TyL

- Magnus

[MartenR]

It is a known issue, that vomp cuts some of the last seconds of a recording. (Playback is terminated, if no additional data is supplied, since the buffers are still filled and  very large, this is  before the real end of the recording).

It can also be an issue of problems of the frame counting algorithm in vdr.
These issues should go away after vdr version 2.0.0 is release and maybe an additional release of vomp. (The problem is that it was changed in the development tree multiple time in vdr, and we are unable to cope with all variants).

Marten

[sirwio]

I'm not so sure that the termination of the playback is due to cutting of the last seconds of the recording. The exact spot where it terminates is where there was a long audio breakup during live tv watching.

Will test again and continue recording for a bit longer after the audio breakup to see if the behaviour is the same e.g. that playback of the recording terminates at the time where the stutter was observed during live tv and not due to being close to the end of the recording.

Hopefully Klaus et al. can get 2.0 as scheduled at the end of this month. Its been a while since there was a "stable" vdr release. Meanwhile I try to do my fair bit of testing tweaking out issues on the 1.7 branch.

[sirwio]

The test confirms that it is the known defect cutting of the last seconds of the recording that was the reason for the terminated playback. Did a longer recording that got two, two second long audio breakups. None of them caused termination of playback. Must have been pure circumstantial that the termination of the original, posted, recording did terminate at the location of the audio breakup.

Interesting is that the audio breakups are not second long during playback but much shorter. Is this in line with possible issue with the frame counting algorithm?

- Magnus

[MartenR]

Interesting is that the audio breakups are not second long during playback but much shorter. Is this in line with possible issue with the frame counting algorithm?

No, the frame counting thing can be related to earlier termination than usual, but not cause an audio problem.
Anyway, when testing your sample, I recognized unusual error messages from the libav audio decoder.
It might be a problem related to a certain packing of the mpeg audio frames into pes packets
The other thing, which is possible are damaged time codes, but the reception seem to be good.
Another possibility are network problems, so that a buffer run out, due to a high data rate.
You can change the TCP receive window setting or improve the network connection.

Marten

[MartenR]

Can you test if it works better before "Add mpeg audio header parser".

Marten

[sirwio]

The raspberry pi client and the vdr server are hooked up to the same gigabit switch. The connection between the two has been measured using iperf and the stats are good:
* 93.7 Mbit/sec with the raspberry pi idle
* 74.8 Mbit/sec with vompclient receiving a 720p HD live tv stream.

During my tests I have had the TCP receive window size setting set to the maximum (65536). Have tested with lower settings as well with no improvements.

The long audio drops where still there on commit 9e0c17153dc97a6ce43e21008f94523a22885855

Code Select Expand

pi@raspberrypi ~/vomp/vompclient-marten $ git reset --hard 9e0c17153dc97a6ce43e21008f94523a22885855
HEAD is now at 9e0c171 Fix in downmix code + integer mixing code

I have also suspected the reception since this is on a new DVB-S2 hardware but since the glitches are not present while watching using softhddevice I have ruled that out. The picture is also perfect during the audio drops...

While starting vompclient with -d I notice tons of messages like:
    Last message repeated 7 times
[mp3 @ 0x271fca0] incomplete frame
09:55:34.855879 [debug]  9185 Audio - We can not decompress 384 save for later 1 b0129588 0
    Last message repeated 2 times
[mp3 @ 0x271fca0] incorrect frame size
09:55:34.994423 [debug]  9185 Audio - saved audio: 768
    Last message repeated 7 times

while watching the troublesome channels. In some previous posts on this forum I have gotten the impression that these shall not be problem - Is that correct?

- Magnus

[MartenR]

Please check last commit.
vomp should now never generate libav error messages. If they appear, than sth is wrong.

Marten

[sirwio]

The last commit makes the libav error messages to be much less frequent. At first I thought they were completely gone but I have seen a few.

There are still messages like the ones pumping to the console while watching the 720p channels and one

22:21:31.316765 [debug]  15630 Audio - We can not decompress 64 save for later 1 b01076c8 0
22:21:31.384563 [debug]  15630 Audio - We can not decompress 560 save for later 1 b01074d8 0
22:21:31.580774 [debug]  15630 Audio - We can not decompress 288 save for later 1 b01075e8 0
22:21:31.749390 [debug]  15630 Audio - We can not decompress 16 save for later 1 b01076f8 0
22:21:31.925575 [debug]  15630 Audio - We can not decompress 512 save for later 1 b0107508 0
22:21:32.139705 [debug]  15630 Audio - We can not decompress 240 save for later 1 b0107618 0

Have still gotten some long audio drops but it appears to happens much less frequently (about two per ten minutes viewing). It may however depend on the show/movie broadcasted. I will continue testing during the weekend.

- Magnus

[MartenR]

Try to generate a sample TS file with the audio drop, so that I can reproduce it.
The messages just say, that some audio frames are spread over two pes packets.

Marten

[sirwio]

A TS file is available to download using the link below:
http://ubuntuone.com/6oZtwz8QdL4nC1IXpCYhES

There were two audio drops in a row - the first one around 2:00 and the other a few seconds later while viewing it live.
During playback the audio does not drop but there is a video stutter around 2:00 and 2:08.

- Magnus

[MartenR]

I am not going to download it.
If the problem is only visible in live tv, a recording will not help.
Anyway, it sounds like there are either a problem in the network or that buffers are too small.

The only way to solve the problem is that you are fiddling with the buffer sizes yourself (please change only one buffer size at once).

I will try to give a complete list of buffers involved in live tv:

• defines.h,120: PLAYER_MAX_STREAMING_BUFFERS; this determines the maximum size of incoming buffers for the whole ts stream before demuxing
• playerlivetv.cc,80:demux_video_size, outgoing demux buffer for video
• playerlivetv.cc,78:demux_audio_size, outgoing demux buffer for audio
• playerlivetv.cc,87:text_fak, outgoing demux buffer for teletext (can also block audio and video, do not ignore)
• videoomx.cc,1723:port_def_type.nBufferCountActual, number of omx buffers for video
• audioomx.cc,1148:port_def_type.nBufferCountActual, number of omx buffers for audio (value in the moment very small. may be the best start point)

May be the problem is subtitle related, what happens without subtitles?

Marten

[sirwio]

Agreed. I will get my hands dirty and play around with the source code.
Don't think its subtitle related since I have noticed the audio drops on swedish spoken broadcast without subtitles as well.

[sirwio]

Last night I started testing by changing the buffers, one at a time, evaluating the impact during live tv. The problem with audio drops are however not happening that often and also appears to depend on the actual broadcast. I'll bet the shows my wife is watching are giving more errors...

Did not notice any improvements for the first few buffers I changed but soon realised this is going to take a long time to complete. I need something that is reproducible. As it turns out the last uploaded file has a micro stutter during playback at the location of where the audio drop was at the time of live viewing. It suggest that the problem are related but manifests itself differently. Regardless the micro stutter is annoying and needs to be fixed as well.

Have tested the recording both downloaded to the pi and streamed from streamdev-server using omxplayer. Both ways give s a micro stutter free playback.

So far I have tested increasing the audio input buffer to the same value as reported by omxplayer. It did not fix the issue. Interesting though is that at exactly the location of the microstutter there is a libav error.
[mp3 @ 0x18369a0] Header missing

Are these libav errors due to missized buffers or is it something else that may cause these?

Anyway I will continue modifying the rest of the suggested buffers.

[MartenR]

No, the libav messages says, that something is broken.
It can be due to an error in the stream, or a misdetection of a header start by vomp.

Marten