Messages

Yes I have the same problem with skipping; sometimes it works fine, others the picture and sound freeze and only a 'kill -9' will regain control. I've been waiting for a chance to create a good log file showing the problem.

Is this expected behaviour?

Code Select Expand


12:21:34.893190 [debug]  1993 Video - Setting aspect to 0
12:21:34.893804 [notice] 1993 Video - Found native mode 1280x720 60 Hz i: 0
12:21:34.894017 [notice] 1993 Video - Found native mode 1280x720 50 Hz i: 0
12:21:34.894141 [notice] 1993 Video - Found close to optimum mode 1920x1080 50 Hz i: 1
12:21:34.894262 [notice] 1993 Video - Found optimum mode 1920x1080 50 Hz i: 0
12:21:34.894431 [notice] 1993 Video - Switch to optimum mode


It seems strange to upscale SD video to 1080p only for the TV to downscale it again.

Actually I see in the latest patch that the native mode is ignored:

Code Select Expand


+               //Now first determine native resolution
+               int native_width=1920;
+               int native_height=1080;
+               for (int i=0;i<all_my_modes;i++) {
+                       if (all_supp_modes[i].native) {
+                               mymode=all_supp_modes+i;
+                               Log::getInstance()->log("Video", Log::NOTICE, "Found native mode %dx%d %d Hz i: %d",
+                                               mymode->width,mymode->height,mymode->frame_rate,mymode->scan_mode);
+                       }
+
+               }


Native_width and native_height are never set to the values for the native mode.

I've also had 'accidents' when running the vompclient directly from the console. Now I run it from a shell script.

There is a new release of firmware for the RPi which is claimed to give improved audio quality through the analogue output as well as fewer clicks.

http://www.raspberrypi.org/archives/2008

Technical discussion on the audio problems is here:
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=38&t=10538

Please try current git. Should be fixed.

Yes that works OK for me. Many thanks.

It seems that the GPU on the Raspberry Pi buffers about six seconds of playback. The calculations for skipping backwards and forwards are based on the frames being fed into the GPU, while the TV is showing video from six seconds earlier. Hence a 10 second forwards skip actually jumps about 16 seconds, while a 10 second backward skip goes back only 4.

This quick-and-dirty patch adjusts the skip timings to allow for GPU buffering.

Code Select Expand


diff --git a/player.cc b/player.cc
index 1650ed4..494d199 100644
--- a/player.cc
+++ b/player.cc
@@ -33,6 +33,7 @@
#include "osdreceiver.h"

#define USER_RESPONSE_TIME 500 // Milliseconds
+#define OMX_BUFFER_SECONDS 6.0 // Float seconds

// ----------------------------------- Called from outside, one offs or info funcs

@@ -418,6 +419,9 @@ void Player::skipForward(int seconds)
   ULONG newFrame = getCurrentFrameNum();
   if (newFrame == 0) { unLock(); return; } // Current pos from demuxer is not valid
   newFrame +=(ULONG) (((double)seconds) * fps);
+#ifdef VOMP_PLATTFORM_RASPBERRY
+  newFrame -=(ULONG) (((double)OMX_BUFFER_SECONDS) * fps);
+#endif
   if (newFrame > lengthFrames) { switchState(S_PLAY); unLock(); }
   else switchState(S_JUMP, newFrame);
//  unLock(); - let thread unlock this
@@ -430,6 +434,9 @@ void Player::skipBackward(int seconds)
   long newFrame = getCurrentFrameNum();
   if (newFrame == 0) { unLock(); return; } // Current pos from demuxer is not valid
   newFrame -= (ULONG) (((double)seconds) * fps);
+#ifdef VOMP_PLATTFORM_RASPBERRY
+  newFrame -=(ULONG) (((double)OMX_BUFFER_SECONDS) * fps);
+#endif
   if (newFrame < 0) newFrame = 0;
   switchState(S_JUMP, newFrame);
//  unLock(); - let thread unlock this


If I try to exit the vompclient by pressing the '7' key from the main menu (rather than by using the up/down and OK keys), the client shows a 'connection lost' box and the keyboard locks. This is the fix:

Code Select Expand


diff --git a/vwelcome.cc b/vwelcome.cc
index cb88da6..dad013a 100644
--- a/vwelcome.cc
+++ b/vwelcome.cc
@@ -189,6 +189,7 @@ int VWelcome::handleCommand(int command)
     case Remote::SEVEN:
     {
       Command::getInstance()->doReboot();
+      return 2;
     }
     case Remote::OK:
     {


Presumably the MVP never returned from doReboot(), but the RPi version does, and it then falls into the next part of the case statement.

I made a little change to the recording playback.
Now you can also use the arrow keys for:
up=play
down=pause
right=fast forward
left= fast backward

I hope this enough for your remote to use all functions of the recording playback.

Excellent! Many thanks.

Hi davep,

is it possible for you, to test this image http://www.minidvblinux.de/download.php?file=3.0.1-rpi//MLD-3.0.1-rpi_vomp-client-2012.09.10_48.tgz again your vdr server?

Claus

Sorry I don't have any spare SD cards at the moment to test your image.

Just for reference, my current todo list (subject to change):

1) Add ac3 passthrough mode and fix audio playback on certain channels (e.g. mono is broken).
2) Handle video mode switch e.g. setting to PAL 50 Hz video modes and handle switching of hdmi and composite, if a connectors is plugged in. Switching video and audio off.
3) Rewrite OSD and surface class to be vector based and to use OpenVG.

It would be good to have:

4) Reconfigure key mapping for CEC remotes via config file.

My TV remote doesn't have buttons for 'skip', 'pause' etc, so I would like to remap the RGYB buttons to these functions, but only in Play mode. XBMC has this ability.

I've just tested my installation and I have no problem viewing live SD TV or recordings (I don't have an HD card). I'm running the latest vompclient on an up-to-date Raspbian distribution (with MPEG2 enabled), and vdr 1.7.29 on the server.

OK it works when I change the Pi to 128/128 memory mode. I was running 192/64 which is enough for oxmplayer.

Thanks for the hint, looking forward to further developments.

Dave

Is the Raspberry Pi client on git.vomp.tv working, ie able to show recordings?

I've compiled the code on my up-to-date Raspbian installation (with hardware MPEG2 enabled). The client connects to the vdr server and I can see the OSD. However when I try to play a recording all I see is the console screen with the OSD time-bar at the bottom. The logs seem to show the client downloading data from the server and handing it on to the display, but eventually error messages "Deliver MediaPacket no free sample" appear.

Incidentally, while working through the logs I noticed another error - "TCP - Too many reads" at the point where playback is started. This seems to be caused by the TCP window size, which on the MVP was set to 2048 bytes because of its very limited buffer space. On the RPi I suggest it is not necessary to limit TCP in this way, and commenting out the code cleared the error with no obvious ill effects.

Dave

Yes iPlayer is an IP TV service provided by the BBC, available only to UK IP addresses. Programmes can be downloaded using a tool such as 'get_iplayer' which stores HD content as mp4 files.

I don't know anything about the pros and cons of the different graphics subsystems, but it seems that the ability to create a standard OSD irrespective of the media being displayed would be important. In the future I would hope to be able to show standard DVB, iPlayer 'HD' content (720p mp4) and full broadcast HD, and have the same OSD for all of them.