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 (http://ubuntuone.com/4nvxpjRVgqSHxruSao2TyL)
- Magnus
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
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.
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
QuoteInteresting 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
Can you test if it works better before "Add mpeg audio header parser".
Marten
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
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
Please check last commit.
vomp should now never generate libav error messages. If they appear, than sth is wrong.
Marten
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
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
A TS file is available to download using the link below:
http://ubuntuone.com/6oZtwz8QdL4nC1IXpCYhES
(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
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
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.
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.
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
Since the last post I have tested various buffer settings without any improvements. Since playback is fine with omxplayer and omxplayer is using ffmpeg and not libav I spent some time compiling ffmpeg and compiled a vompclient version using ffmpeg instead of libav. Did not improve anything.
Is there a way to dump the stream, by modifying source code on the client and/or server side, to a file to check if the problem is with the streamed data? Suggestions on where and how this could be done would be appreciated.
There is something else you can use for diagnosis.
In AudioOMX::AdvanceMpAudioSync you can uncomment the log lines with the FRAME messages.
For one television station, they should not change, if they change, it is possible, that the algorithm detect non audio frames as audio frames.
For dumping the stream, you can use DeliverMediaPacket. You can put write the data at various places to a file here. Before and after decoding.
Marten
So I uncommented the logs in AudioOMX::AdvanceMpAudioSync and can observe the following:
Whenever there is some libav error the logs look like below (greping only logs with text Audio)
15:00:01.116161 [debug] 5064 Audio - FRAME: 0 2 12 48000 0 256 768
15:00:01.118679 [debug] 5064 Audio - FRAME DIAG: ff fc c4
15:00:01.120568 [debug] 5064 Audio - FRAME: 0 2 12 48000 0 256 768
15:00:01.122935 [debug] 5064 Audio - FRAME DIAG: ff fc c4
15:00:01.248154 [debug] 5064 Audio - FRAME: 0 2 12 48000 0 256 768
15:00:01.248326 [debug] 5064 Audio - FRAME DIAG: ff fc c4
15:00:01.253840 [debug] 5064 Audio - FRAME: 0 1 10 48000 0 320 320
15:00:01.255390 [debug] 5064 Audio - FRAME DIAG: ff fa a5
Last message repeated 2 times
[mp3 @ 0xd3bea0] incomplete frame
15:00:01.262895 [debug] 5064 Audio - FRAME: 0 1 10 48000 0 320 320
15:00:01.266083 [debug] 5064 Audio - FRAME DIAG: ff fa a5
15:00:01.269644 [debug] 5064 Audio - FRAME: 0 1 10 48000 0 320 320
15:00:01.271737 [debug] 5064 Audio - FRAME DIAG: ff fa a5
15:00:01.427507 [debug] 5064 Audio - FRAME: 0 1 10 48000 0 320 320
15:00:01.427676 [debug] 5064 Audio - FRAME DIAG: ff fa a5
15:00:01.428898 [debug] 5064 Audio - FRAME: 0 2 12 48000 0 256 768
15:00:01.429013 [debug] 5064 Audio - FRAME DIAG: ff fc c4
15:00:01.437340 [debug] 5064 Audio - FRAME: 0 2 12 48000 0 256 768
15:00:01.438675 [debug] 5064 Audio - FRAME DIAG: ff fc c4
15:00:01.444627 [debug] 5064 Audio - FRAME: 0 2 12 48000 0 256 768
15:00:01.446386 [debug] 5064 Audio - FRAME DIAG: ff fc c4
15:00:01.451323 [debug] 5064 Audio - FRAME: 0 2 12 48000 0 256 768
15:00:01.454851 [debug] 5064 Audio - FRAME DIAG: ff fc c4
15:00:01.457935 [debug] 5064 Audio - FRAME: 0 2 12 48000 0 256 768
15:00:01.466471 [debug] 5064 Audio - FRAME DIAG: ff fc c4
Is this an indication of something broken in the stream or in the frame detection algorithms?
As for the longer audio drops there were at least a few where the FRAME message did not change - nor where there any libav errors.
Yes,looks like a frame misdetection.
I suspect that line 1583 in AudioOMX::AdvanceMpAudioSync (audioomx.cc) is parsing the layer description bits incorrectly.
1583 int layer=4-(data[test+2]&0x03)>>1;
The layer is as far as I can tell it located in position bit 18 and 17 of the mpeg audio frame header e.g in data[test+1]. The layer would then be calculated as:
int layer = 4 - ( (data[test+1] & 0x06) >>1 );
Does this make sense or have I totally misunderstood how the parsing is done?
Am i correct in the understanding of the local variable mpeg2 that its actually a variable holding status if the frame is an mpeg version 2.5 audio frame or not.
But what is the lsf variable?
You are correct, this is wrong. Thanks. (I will commit this soon).
Regarding the mpeg2 variable I think it indicates mpeg version 2.5.
lsf indicates mpeg2 vs. mpeg1, if I remember correctly.
Marten
Thanks. I have figured out the lsf variable as well especially why it was also set when an mpeg 2.5 frame was detected.
I still get some libav errors. On at least one of them the layer value was a reserved value (00). Checking the libav source code I noticed they perform a santiy check on the header not only checking if the framesync is correct but also checking the values of the layer, bitrate and frequency.
A comment of the method making the header check in libav says: "fast header check for resync".
Will test with such checks in place to see what happens.
Another discrepancy between the documentation I have found, http://mpgedit.org/mpgedit/mpeg_format/mpeghdr.htm#MPEG%20HEADER (http://mpgedit.org/mpgedit/mpeg_format/mpeghdr.htm#MPEG%20HEADER), and the libav implementation is how the frame size is calculated. According to the doc the frame size should be calculated the same for layer 2 and layer 3 messages but in the libav implementation they differ. The docs does however not claim to be accurate... Do you have a pointer to some other documentation on the the mpeg audio frame header.
Quotenot only checking if the framesync is correct but also checking the values of the layer, bitrate and frequency.
It might be necessary to implement this as well....
I have no additional documentation for mpeg audio than the ones you mentioned. There might be the specification...
Marten
Attached is a patch that will check the mpeg audio header before attempting to parse it. I have kept the implementation simple since I assume it will be rewritten if added to the sources.
The header check is implemented in a helper function private to the class AudioOMX named checkMpAudioHeader
There is one check that is questionable and that is the check if the bitrate index is of type "free format". Since the current code does not appear to take the "free format" into account when the bitrate is calculated I chose to include it in the helper. Its questionable since a function named checkMpAudioHeader shall only check the header and not perform application logic. (In this case invalidating the header if the bitrate index is of type "free format".
With this change there are no more audio drops during live tv. There are however occasional audio "chirps" during both live and playback of recordings on the 720p channels.
When the "chirps" occur there are, with the patch applied, messages about various mpeg header inconsistencies as well as libav errors:
[mp3 @ 0x7ecb60] big_values too big
[mp3 @ 0x7ecb60] Error while decoding MPEG audio frame.
Since recordings play fine using other methods I must ask. Is the vompserver plugin modifying the stream before its sent in some way compared to e.g. the streamdev plugin? In other words. Is the problems I see perhaps on the server side and not on the client side.
I will look into the patch and implement sth. similar.
QuoteSince recordings play fine using other methods I must ask. Is the vompserver plugin modifying the stream before its sent in some way compared to e.g. the streamdev plugin? In other words. Is the problems I see perhaps on the server side and not on the client side.
Of course vomp modifies it in some way. Everything is done on the client side.
We have a demuxer, then the parsing code in audioomx. Everything there can have an error which drops some data.
Also it is possible that the playerlivetv has droped some data, look for the log message "Dropped chunk", if this occurs the number of max buffers PLAYER_MAX_STREAMING_BUFFERS defined in defines.h is too small.
Anyway the message, "big_values too big" is a sanity check in side the mpeg audio layer 3 decoder. Since audio should be layer 1 or 2 in DVB (check this please for your channel), it is very likely, that it is still not synced properly.
Marten
I have implemented sanity checks similar to your checks.
Please test it.
Marten
The implementation works as good as mine.
I still have annoying high frequency chirps once in a while but the client is now usable. There are no log entries indicating that buffers are full.
The specs of the channels are http://www.svt.se/omsvt/om-sandningarna/hdtv/expertinformation (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
Quoteannoying high frequency chirps
These are probably still misdetected mpeg audio frames. But I do not know how to identify them.
Anyway, I suggest, that you select the ac3 audio track, since all your problems are related to mpeg audio.
Marten
I just realized while looking at your implementation that the layer description sanity test is not correct.
Its the value of
(data[test+1]&0x06)>>1
that shall be checked if its zero. NOT the calculated layer variable :-)
Choosing the ac3 audio track makes the chirps go away but in that case there are libav ac3 errors in the log as well as occasional disturbances in the audio. Much less annoying than the audio chirps but still audible:
I will continue looking into the demuxer and audio parsing code. It annoys me a lot not finding the root of the problems I see.
01:52:36.962970 [debug] 2309 Audio - warning we only support 48 KHz sampling rate
Last message repeated 1 times
[ac3 @ 0xc03340] invalid sample rate
01:52:41.043573 [debug] 2309 VDR - Sending KA packet
01:52:41.047933 [debug] 2309 VDR - Rxd correct KA reply
01:52:44.727333 [debug] 2309 Audio - warning we only support 48 KHz sampling rate
[ac3 @ 0xc03340] invalid bitstream id
01:52:47.037351 [debug] 2309 VDR - Sending KA packet
01:52:47.045016 [debug] 2309 VDR - Rxd correct KA reply
01:52:53.021903 [debug] 2309 VDR - Sending KA packet
01:52:53.024487 [debug] 2309 VDR - Rxd correct KA reply
01:52:59.047240 [debug] 2309 VDR - Sending KA packet
01:52:59.052316 [debug] 2309 VDR - Rxd correct KA reply
01:53:00.000099 [debug] 2309 Timers - Timer firing for client 0xc2407c ref 1
01:53:00.001678 [debug] 2309 Timers - Timer firing for client 0xc1ab94 ref 2
01:53:00.003375 [debug] 2309 Timers - sending timer to 0xc2407c with parameter 1
01:53:00.010658 [debug] 2309 Timers - sending timer to 0xc1ab94 with parameter 2
01:53:00.013072 [debug] 2309 VVideoLiveTV - Timer Call 2 start.
01:53:00.015855 [debug] 2309 Timers - Starting set timer 1
01:53:00.016964 [debug] 2309 VVideoLiveTV - Timer Call 2 end.
01:53:00.017663 [debug] 2309 Timers - timerEventFinished for 0xc1ab94
01:53:00.019067 [debug] 2309 Timers - timerEventFinished RESTART for 0xc1ab94
01:53:00.014019 [debug] 2309 Timers - Starting set timer 1
01:53:00.020865 [debug] 2309 BoxStack - Update called
01:53:00.021624 [debug] 2309 BoxStack - Locked for update
01:53:00.022474 [debug] 2309 BoxStack - Unlocked for update
01:53:00.023312 [debug] 2309 Timers - timerEventFinished for 0xc2407c
01:53:00.024435 [debug] 2309 Timers - timerEventFinished RESTART for 0xc2407c
01:53:05.006448 [debug] 2309 VDR - Sending KA packet
01:53:05.017063 [debug] 2309 VDR - Rxd correct KA reply
01:53:11.036978 [debug] 2309 VDR - Sending KA packet
01:53:11.042163 [debug] 2309 VDR - Rxd correct KA reply
[ac3 @ 0xc03340] frame CRC mismatch
01:53:15.819078 [debug] 2309 Audio - warning we only support 48 KHz sampling rate
[ac3 @ 0xc03340] Additional substreams not implemented. Update your Libav version to the newest one from Git. If the problem still occurs, it means that your file has a feature which has not been implemented.
[ac3 @ 0xc03340] If you want to help, upload a sample of this file to ftp://upload.libav.org/incoming/ and contact the libav-devel mailing list.
[ac3 @ 0xc03340] unsupported frame type : skipping frame
01:53:17.034369 [debug] 2309 VDR - Sending KA packet
01:53:17.039655 [debug] 2309 VDR - Rxd correct KA reply
01:53:23.030194 [debug] 2309 VDR - Sending KA packet
01:53:23.033451 [debug] 2309 VDR - Rxd correct KA reply
01:53:29.026229 [debug] 2309 VDR - Sending KA packet
01:53:29.031699 [debug] 2309 VDR - Rxd correct KA reply
01:53:35.024122 [debug] 2309 VDR - Sending KA packet
01:53:35.027782 [debug] 2309 VDR - Rxd correct KA reply
01:53:41.026716 [debug] 2309 VDR - Sending KA packet
01:53:41.031866 [debug] 2309 VDR - Rxd correct KA reply
01:53:47.034125 [debug] 2309 VDR - Sending KA packet
01:53:47.038614 [debug] 2309 VDR - Rxd correct KA reply
01:53:53.032517 [debug] 2309 VDR - Sending KA packet
01:53:53.036165 [debug] 2309 VDR - Rxd correct KA reply
01:53:54.520081 [debug] 2309 Audio - warning we only support 48 KHz sampling rate
[ac3 @ 0xc03340] invalid bitstream id
[ac3 @ 0xc03340] frame CRC mismatch
01:53:59.009119 [debug] 2309 VDR - Sending KA packet
01:53:59.014178 [debug] 2309 VDR - Rxd correct KA reply
01:53:59.402754 [debug] 2309 Audio - warning we only support 48 KHz sampling rate
[ac3 @ 0xc03340] incomplete frame
01:54:00.000155 [debug] 2309 Timers - Timer firing for client 0xc2407c ref 1
I have fix the sanity check.
QuoteI will continue looking into the demuxer and audio parsing code. It annoys me a lot not finding the root of the problems I see.
I think it is very likely, that all problems originate from "DeliverMediaPacket". It is very likely, since you mentioned, that there is no problem on the mvp.
For the ac3 data you can compare passthrough mode and non passthrough mode. In the case of passthrough mode, you would not see any libav messages, since everything is done in the tv, but if the data delivered to "DeliverMediaPacket" is corrupt, you will hear it.
If everything is working fine, that error must be after the "else" related to "if (passthrough) {".
Good luck!
Marten
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
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?
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
@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
@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
@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 (https://drive.google.com/file/d/0B4LQIJR9gOUmamc3TW14NVQ5UFk/edit?usp=sharing)
@sirwio
First chirps at about 1:00. I will check your file.
CU
winschrott
@sirwio
Interesting I will look into it.
I can confirm a first chirp at 54s and a second at 1min12s in the recording provided by winschrott.
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
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
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
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
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
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
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
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 ;-)
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
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 :o !? 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
There are other sanity checks in this function.
All with an if clause and continue.
Marten
Hello Marten,
for me the following changes seem to work:
audioomx.cc, Line 1582ff:
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
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
@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
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
@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
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
@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
(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.
QuoteThe 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.