Audio breakup's on 720p channels.

[MartenR]

How do you know that it is error free?
Just by playing it back by a software?

This only proves that the error detection of the software is better. If you want to know if it is really broken, you have to use the Hex editor.

The pes packets are delivered to "DeliverMediaPacket(MediaPacket packet, const UCHAR* buffer,                  UINT *samplepos) " in audioomx.cc, you can get the audio stream from there in write it to a file. This is what I usually do to check the stream.
Also if there is a error in audio stream processing, it is probably there.

Marten

[winschrott]

Hello Marten,

I tried to check the TS-file (recording) with several tools. Actual I´m playing with MPEG-2 TS packet analyser (incl. hex-editor). Error-correction should be done before by using the additional forward-error-correction bytes in the stream which is originally 208 bytes long per packet, for example.
The question is where the errors occur. And if it is "only" a packet misdetection - why?

-winschrott
Out now, qualifying now and football in a few minutes ;-)

[MartenR]

Sometimes the error correction does not work and then some packets are missing.
All I have figured out that the stream was out of synch, and the resynch occured at some, which looked like an mpeg audio header but was actually inside  the audio frame.
I adapted than the mechanism, that also libav uses to detect these cases.

Marten

[winschrott]

Hello Marten,

I tried several things, at last I added a line which gives me debug information in case of NOT mp3sameheadercount>1...4
I get several log-entries from this line with no audible dropouts, but sometimes (60%) NOT when my audio is dropping. In this case the log is empty    !? So it should be an other problem here. Will audio packets be dropped at any other position in case of an error?
I will try to up a short file with some audio dropouts...

CU
winschrott

[MartenR]

There are other sanity checks in this function.
All with an if clause and continue.

Marten

[winschrott]

Hello Marten,

for me the following changes seem to work:

audioomx.cc, Line 1582ff:

Code Select Expand


while ( size - test >= 3) {
if (data[test]==0xFF && (data[test+1] &0xe0)==0xe0) {  // 11bit frame sync
if ((data[test+1] & 0x18) == 0x08) {test++;continue;}  //sanity check: mpeg version ID 01 -> reserved
//sanity check inspired by libav
...


I will give it to the friend of mine with the same problem and will report later. But it seems good!

Background:
I think the most important change is to ignore data with the reserved mpeg version 01 which is done in line 3 of my code. The other change belongs to the loop which ends some bytes earlier now but should meet the requirements with more accuracy.

Could be possible that line 1641ff

Code Select Expand


if (mp3sameheadercount>4) {
*framesize=frame_size;
return test; // probably FrameSync
} //skip it if the header changes too frequently


will be obsolete with these changes. I will try the next days.

Happy christmas,

winschrott

[MartenR]

@winschrott
Thanks for the fix, I have included it in my git.
I will leave the header continuity check, since I think it can prevent playing back garbage. (May be the counter should be decreased).

Marten

[sirwio]

I have briefly for a few hours tested the latest git commit and there are occasionally frames with reserved version id detected. Not many at all but perhaps a few per ten minutes during my tests.

Did as well test with the increased accuracy of ending the loop but cannot yet tell if that improves things or not.

What really made it possible for us to go into "production" with the vompclient pi's was the header continuity check. Please don't remove that. Tested without it (but with the reserved version id check) and got the nasty audio chirps back on our 720p channels.

- Magnus

[winschrott]

@sirwio

I did a lot of tests the last hours and had no more audio chirps. Did you try other vdr-client-software, for example the new raspihddevice?
Could you give me an actual test-file with chirps? Please not too small, no problem if the file is about 100MB or so. The best would be an original TS-file. What channels are affected?

Thanks,

winschrott

[MartenR]

I will keep the audio header continuity test.
It is part of the all the other sanity checks and also ffmpeg/libav use a continuity test.
It is very likely that you are not experiencing any problems without the test.
But the odds are high that someelse does has problems.
So I will leave it in the code.

Marten

[sirwio]

@winschrott
Below is a link to a small, 35MB, recording with an audible audio chirp about 5 seconds into the recording. I hope the recording is not too small.

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


The clip is from SVT2 HD - A 720p public service channel broadcasted in Sweden. The format of the channel is as mentioned previous in this thread.

The specs of the channels are http://www.svt.se/omsvt/om-sandningarna/hdtv/expertinformation:
Video
H.264/AVC/MPEG-4 Part 10 with variable BitRate (VBR). Practically this means that the bitrate may vary between 4 and 16 Mbit/s.

Audio
Both stereo and 5.1 multichannel. The 5.1 sound is coded as Dolby Digital (AC3) @ 448 kbit/s. The stereo sound is coded as MPEG1-L2@256kbit/s

The recording does not give any audio chirp when played using the rpihddevice.