Audio breakup's on 720p channels.

[winschrott]

Hello,

I have the same problems with short audio chirps with ORS-SD-channels. HD is OK. I implemented the patches above and tried some alternative settings for the buffers.
The problem belongs to livetv and playing of recordings. No chirps with MVP, VLC or another VDR (VDPAU). Only DVB-S (SD) is affected, DVB-T and DVB-S2 (HD) comes without any chirps. I give you an upload of a sample file with chirps but it is 920MB: http://www.ctmd.de/fileadmin/00001_original.ts
Tell me if I should cut some chirps (what kind of software should I use?)...

@Sirwio:
Did you find something about these audio chirps? As I read about the affected channel, the audio bit rate is fixed to 160kbps. I think, I should do some debugging to see if there are similar changes in bitrate and codec like in your 720p stream. This would lead to think about misdetected audio-frames, right?

Thanks,
winschrott

[sirwio]

It is still an issue to me. Did quite a lot of debugging last spring without any success. It was also a bit discouraging that I was the only one having the problem. About a month ago I even bought a second pi with 512MB RAM just to make sure it was not related to me having a 256MB model. Same thing with the new pi.

Still I have great hope that this problem will be solved. Especially since there actually appears to be others experiencing the glitch with the sound. Any chance you could make available a short snippet of a recording showing the problem?

[winschrott]

Hello sirwio,
I uploaded an really big file. Could you tell me what kind of software I should use to cut some chirps without changing something in the original stream?
I tried to use MPEG2Repair to check the stream (no errors found) and to repair the stream (nothing changed). This was only an idea. Also generating a PS with PVAStrumento gives me a clean PS-file, no errors found.
I use several PIs with 512MB RAM, actual Raspbian and VOMPClient from git (server is 0.4.0, changed the PROTOCOLL_VERSION client-side to 200, running), audio output via HDMI or analog output (same problem).

winschrott

[MartenR]

@winschrott
Can you please you use the client from my git?
Combined with a server from git using the 0-4-1-dev branch?
I have fixed multiple issues regarding audio since the last release and there is no use doing testing with the last release.

Marten

[winschrott]

@MartenR
I use the client from your GIT. The server is from GIT, too - now!
In the source I found the last bugfixes from this thread so I think I got the right source ;-) Are there any other changes than header sanity check and corrections belonging to frame / rate detection?

CU
winschrott

[sirwio]

@winschrott - I have downloaded your recording but has not yet been able to test it. My dev rpi did not have the mpeg2 decoder license "installed". Will take a look at it tomorrow.

As reference I'm making available a short 130MB 720p recording that has a lot of audio chirps at the beginning. It still has problem with the latest vompclient-marten and 0-4-1-dev.

https://drive.google.com/file/d/0B4LQIJR9gOUmamc3TW14NVQ5UFk/edit?usp=sharing

[winschrott]

@sirwio

First chirps at about 1:00. I will check your file.

CU
winschrott

[MartenR]

@sirwio
Interesting I will look into it.

[sirwio]

I can confirm a first chirp at 54s and a second at 1min12s in the recording provided by winschrott.

[MartenR]

I have looked at sirwios sample. (The other one is too big...., I need short samples, downloading or debugging will be a pain otherwise)

I have implemented a function, which assumes if the mpeg audio header changes frequently,
that the audio is not in synch or broken. Therefore the audio is discarded until the format stays the same. (inspired by libav's code).

This might solve your problem with mpeg audio.
Now in my git.

Marten

[winschrott]

Hello marten,

thanks for debugging.
Now there are no chirps anymore but instead of the chirps I get audio-dropouts for about 0.5-1 sec. ´vompclient -d´ does not give any output in case of these dropouts.
Tell me if I can help you with debugging,...

One idea:
You detect the actual bitrate and so on of the audio stream. As I understand you, you are now dropping audio-frames with a mismatching bitrate. Would it be - only for a try - be possible to set the bitrate to the "matching" settings for these frames you detect as mismatching ones and send these manipulated frames to the decoder instead of dropping them? No need to change this in your GIT, you can send me the changed source-file via PM or attach it to a message.

Thanks,
winschrott

[MartenR]

You can choose a chirp or a audio drop out.
In case of sirwio, the file was propably damaged in the beginning. (Visible artefacts in the video).
The question is only how gentle the audio is turned off.

You can play with "if (mp3sameheadercount>4) {" in audioomx. May be a value of 2 or 3 is better than 4.

Marten

[winschrott]

Hello marten,

I will cut one or several chiprs out of the old file.
I will also try the alternative settings you mentioned.

What do you think about the idea I edited to my last message?

CU

[MartenR]

No the idea does not help.
The whole stream is out of sync, after the broken stream.
There is a beginning of an audio frame detected which is not the beginning of the audio frame.
Then the algorithm continues to search for the frame.
So that check ensures, that is synching faster.

Marten

[winschrott]

Hello Marten,

i do not really understand how the original TS-Stream is processed by vomp.
Which part does demuxing of the TS and is it possible to extract the demuxed stream(s) to check them for errors? The original TS-stream seems to be error-free so it is not clear to me why vomp loses sync or detects wrong audio-headers.

A friend of mine (yotom) tries your mp3sameheader-settings...

CU
winschrott