News:

Latest versions:
Server plugin: 0.5.1
MVP dongle: 0.5.2
Raspberry Pi client: 0.5.2
Windows client: 0.5.2-1

Main Menu

Add simpler bob deinterlace for 1080i streams....

Started by Uwe, September 25, 2012, 05:46:13

Previous topic - Next topic

hondansx

Thanks Marten.

Send a patch to Chris.
Hope we see it soon in git.  ::)
GA-EP43 | headless | 1xCineS2 Dual | 1xSkystar 2.6D | VDR 1.7.37 
Frontend: 1xRasperry | 1xION3

MartenR

The problem is I am not sure, if this really fixes the problem or if it is  asymptom.
I do not recommend to include it in git now.

Marten

hondansx

Quote from: MartenR on October 03, 2012, 09:29:41
The problem is I am not sure, if this really fixes the problem or if it is  asymptom.
I do not recommend to include it in git now.

Marten

I tested it now, and I believe it fixes only the half. Main vdr will not be killed anymore, but channelswitching is not working.

It works for me if I revert this changes.


- Fixed a race condition when zapping in transfer mode (reported by Reinhard Nissl).
  This involves a slight change in the semantics of the cReceiver::Activate() function,
  which is now called with 'false' *after* the receiver has been detached from the
  device.
diff -ruN vdr-1.7.29/device.c vdr-1.7.30/device.c
--- vdr-1.7.29/device.c 2012-04-04 11:48:21.000000000 +0200
+++ vdr-1.7.30/device.c 2012-08-26 15:25:44.000000000 +0200
@@ -1666,11 +1675,11 @@
   cMutexLock MutexLock(&mutexReceiver);
   for (int i = 0; i < MAXRECEIVERS; i++) {
       if (receiver[i] == Receiver) {
-         Receiver->Activate(false);
          Lock();
          receiver[i] = NULL;
          Receiver->device = NULL;
          Unlock();
+         Receiver->Activate(false);
          for (int n = 0; n < Receiver->numPids; n++)
              DelPid(Receiver->pids[n]);
          }




GA-EP43 | headless | 1xCineS2 Dual | 1xSkystar 2.6D | VDR 1.7.37 
Frontend: 1xRasperry | 1xION3

MartenR

QuoteIt works for me if I revert this changes.
Are all problems gone, if you revert these changes in vdr?

Marten

hondansx

Quote from: MartenR on October 03, 2012, 10:03:22
QuoteIt works for me if I revert this changes.
Are all problems gone, if you revert these changes in vdr?

Marten

Yes.
GA-EP43 | headless | 1xCineS2 Dual | 1xSkystar 2.6D | VDR 1.7.37 
Frontend: 1xRasperry | 1xION3

MartenR

Can you please try the following:
remove "threadStop();" from the destructor of mvpreceiver.
Then put  it before Detach in DetachMvpReceiver.

Also add in the destructor of Vompclient a call to lp->DetachMvpReceiver() before delete lp;

Marten

Uwe

Many thanks to you both MartenR and hondansx!
Now with vdr-1.7.31 everything works again!

And here's the complete patch... :)
--- vompserver-git//mvpreceiver.c       2012-10-03 11:41:07.907972907 +0200
+++ vompserver-new//mvpreceiver.c       2012-10-03 11:55:41.343970348 +0200
@@ -78,8 +78,8 @@

MVPReceiver::~MVPReceiver()
{
-  Detach();
-  threadStop();

   numMVPReceivers--;
   Log::getInstance()->log("MVPReceiver", Log::DEBUG, "num mvp receivers now down to %i", numMVPReceivers);
@@ -106,6 +106,11 @@
   return vdrActivated;
}

+void MVPReceiver::detachMVPReceiver(){
+   threadStop();
+   Detach();
+}
+
void MVPReceiver::Receive(UCHAR* data, int length)
{
   pthread_mutex_lock(&processedRingLock);
@@ -171,3 +176,4 @@
   *destpids=0;
   return mergedSpidsTpid;
}
diff -Nur vompserver-git//mvpreceiver.h vompserver-new//mvpreceiver.h
--- vompserver-git//mvpreceiver.h       2012-10-03 11:41:07.907972907 +0200
+++ vompserver-new//mvpreceiver.h       2012-10-02 12:18:25.447956834 +0200
@@ -38,6 +38,7 @@
     virtual ~MVPReceiver();
     int init(TCP* tcp, ULONG streamID);
     bool isVdrActivated();
+    void detachMVPReceiver();

   private:
     MVPReceiver(cChannel* channel, cDevice* device);
diff -Nur vompserver-git//vompclientrrproc.c vompserver-new//vompclientrrproc.c
--- vompserver-git//vompclientrrproc.c  2012-10-03 11:41:07.911972907 +0200
+++ vompserver-new//vompclientrrproc.c  2012-10-03 11:53:51.727970671 +0200
@@ -1113,6 +1113,7 @@
   log->log("RRProc", Log::DEBUG, "STOP STREAMING RECEIVED");
   if (x.lp)
   {
+    x.lp->detachMVPReceiver();
     delete x.lp;
     x.lp = NULL;
   }

hondansx

I can confirm that this patch works for me too.

@Marten
Can you recommend this for git?

@Chris
If okay, can you put this into the git?

GA-EP43 | headless | 1xCineS2 Dual | 1xSkystar 2.6D | VDR 1.7.37 
Frontend: 1xRasperry | 1xION3

MartenR

Yes I can, except that I also want a call to
lp->detachMVPReceiver();in the vompclient destructor.

Marten


Chris

I have applied the patch to vompserver git. Thanks hondansx, Uwe and MartenR for fixing that.

Uwe

Hi,
i have update my raspbian to https://github.com/Hexxeh/rpi-firmware
I now have a CPU usage of 35% to 90% max by 1080i Channels (eg. ServusTV-HD or DiscoveryHD) with deinterlacer on 720p Mode(hdmi_mode=19   # 720p 50Hz) I have almost no stuttering. (can it be that the new firmware can scale better?)
At 720p Channel i have still this micro stuttering. (I saw that the new GPU firmware can more memory request ... Could be in the vompclient change?)
Overall I think that it works better with this change.
I hope it will soon work with 720p even better... :)

1080i deinterlacer aktivate with:
if (deinterlace!=0 && demux->getHorizontalSize()<=720 || deinterlace!=0 && demux->getHorizontalSize()==1920)

MartenR

I do not activate the deinterlacer until the new firmware went into raspbian.
But in the mean time I change part in the demuxer to parse deinterlacing information,
which should prevent, if the flags are set correctly by the tv station, deinterlacing progressive material.
You can now activate the deinterlacer for HD material with:
if (deinterlace!=0 && demux->getInterlaced())
if you have the right firmware.

Marten

Uwe

Hi Marten,
Thanks for the Tip. :) ... but ...
With the latest firmware and vompclient-git version -> 1080i channels no longer work, only ServusTV HD works, but as AnixeHD and other not work. (Deinterlacer is deaktivated)
(Image starts, sound comes, stand freezes, sound continues for 5 seconds and then falls silent.)
AND ... 720p Channels works fine, without micro stuttering. :D Super!

MartenR

I think they reverted some changes in the firmware in order to release soon a firmware for 512MB.
So it might be that the functionality might come back later.

Marten