Messages

A vompclient 0.4.0 is not compatible with a vompserver 0.3.1

All clients and the server needs to be on the same version.

http://forum.loggytronic.com/index.php?topic=693.0

My SD card got boorked some days ago and I have had to write a new image to the card. Unfortunately my notes of the steps required to setup a working develop environment for the vompclient on the raspberry could not be found...

Wouldn't it be nice to have a sticky post on this forum or perhaps even better - a web page on the loggytronic site like http://www.loggytronic.com/vomp-pi.php

These are the steps I took while setting up my new develop environment. It may not be optimal and can likely be simplified - Some parts may be plain wrong. Suggestions and review especially by Marten and Chris are welcome.

Download the "Rasbian Wheezy" image available from http://www.raspberrypi.org/downloads
Write the image to the SD card following e.g. the instructions on http://elinux.org/RPi_Easy_SD_Card_Setup

Boot Rasbian. Remember, the login username is pi and the password is raspberry. When the initial setup loads, change the memory split to give the GPU 128MB. Change other options to suit. Now execute:

Code Select Expand


sudo su -
apt-get install libavformat53 libmagick++5 liblockdev1
wget "http://www.loggytronic.com/dl/libcec1_1.8.1-1_armhf.deb"
dpkg -i libcec1_1.8.1-1_armhf.deb


At this point the box is configured to execute a vompclient raspberry binary.

The libcec development package below does not currently exist in the dl area. It can be downloaded from the forum sections but I suggest adding it to the dl site to make the setup simplified.

Code Select Expand


wget "http://www.loggytronic.com/dl/libcec-dev_1.8.1-1_armhf.deb"
dpkg -i libcec-dev_1.8.1-1_armhf.deb


Next we need to install various development libraries. Please review if these are the correct development libraries. Especially libmagick++-dev brings in tons of dependencies. Perhaps there are a more lightweight version available.

Code Select Expand


apt-get install libavcodec-dev
apt-get install libavformat-dev
apt-get install libmagick++-dev


Install git so that its possible to fetch the vompclient source code:

Code Select Expand


apt-get install git-core


If we continue to build vompclient at this stage the build will choke with a:

g++ -g -O0 -Wall -Wshadow -DDEV -D_GNU_SOURCE -DVOMP_PLATTFORM_RASPBERRY   -I/opt/vc/include -I/opt/vc/include/interface/vcos/pthreads  -I/usr/include/freetype2 -I/usr/include/ImageMagick  -D__STDC_CONSTANT_MACROS   -c -o osdopenvg.o osdopenvg.cc
In file included from /opt/vc/include/bcm_host.h:50:0,
                 from osdopenvg.cc:36:
/opt/vc/include/interface/vmcs_host/vcgencmd.h:33:52: fatal error: interface/vmc_host/linux/vchost_config.h: No such file or directory
compilation terminated.
make: *** [osdopenvg.o] Error 1

One workaround is to replace line 33 in the file /opt/vc/include/interface/vmcs_host/vcgencmd.h with

Code Select Expand

#include "interface/vmcs_host/linux/vchost_config.h"

A better workaround is likely to add -I/opt/vc/include/interface/vmcs_host/linux to the INCLUDES in the GNumakefile.

exit from the superuser session to fetch and build as user pi

Code Select Expand


exit


Fetch the sources and start the build

Code Select Expand


git clone http://git.vomp.tv/vompclient.git
cd vompclient
make


Congratulation. You should now have a vompclient executable that can be started as:

Code Select Expand


./vompclient


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.

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.

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

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

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

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

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.

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

I have tested with the latest commits from the vompclient-marten repository for the last couple of days and there is no detectable lipsync problems on various channels that we have watched.

Just to clearify my setup. The raspberry pi is connected via hdmi to the tv only so sound is via hdmi directly to the tv.
The last couple of days testing has been done with SD Deinterlacing set to Advanced and AC3 HDMI Mode set to PCM.

I got some issues though with occasional audio break up's  some as long as lasting a couple of seconds while watching live tv on 720p channels.. Will open a new thread for this.

Yes setting the "AC3 HDMI Mode" setting from "PassThrough" to "PCM" did improve playback as well even with "SD Deinterlacing" set to "Advanced".

Not sure if that was the setting you meant:
> If your tv is cable, can you please set AC3 over HDMI to ac3.

My broadcast is DVB-S2

I will test over the weekend to find other shows that show the same errors - perhaps some less chezzy clip :-)

Yesterday I found some threads on the raspberry forums that suggested that overclocking the pi did help. I did not notice any improvement while overclocking to the medium setting.

- Magnus

Setting the Advanced option "SD Deinterlacing" to "None" did improve playback.

With the setting set to "Advanced" I got the following while playback of the troublesome recording:

16:03:37.227910 [notice] 2312 Video - VideoType 1920 x 1080 i: 1
16:03:37.229401 [notice] 2312 Video - Deinterlacing activated 2

Whilst with the setting "None" one only gets the first line.

I can pm you a downloadable link to a snippet of the recording in case you want to check it out. Note that the poor lipsync behaviour is not noticed on all 1920x1080i broadcasts but only on some.

I noticed on some channels especially HD channels that audio is out of sync (poor lip-sync). Made a recording and tested playback using streamdev and the new samsung smart tv app and playback is correct.

Copied the recording locally to the raspberry where I tested playback using omxplayer with the same result. But when omxplayer was started with --refresh argument the playback is correct with proper lip-synch.

The option --refresh does adjust the framerate/resolution to the video.
>   -r / --refresh                 adjust framerate/resolution to video

I noticed the omxplayer said it adjusted to mode 31 so I changed /boot/config.txt to startup at that resolution. Rebooted and playback was then ok using omxplayer without the --refresh argument. But playback using vompclient is still with poor lip-sync.

Any suggestions on how one can get proper playback/live tv with lip sync?

When you troubleshot you could use the cec-client test tool part of libcec.

Test announcing the pi to be e.g. a "Recording Device"
#cec-client --type r

After the client has been started it may be needed to force a scan of the cec connected devices on the tv and choose the correct one from the list. Then press keys on the remote to test if they are forwarded to the pi.

The type can be one of {p|r|t|a} - Playback Device, Recording Device, Tuner, Audio Device

I can run another test on another samsung tv that I got to check if later models behave the same.