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

[hondansx]

Thanks Marten.

Send a patch to Chris.
Hope we see it soon in git. 

[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]

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.

Code Select Expand


- 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]);
          }


[MartenR]

It works for me if I revert this changes.

Are all problems gone, if you revert these changes in vdr?

Marten

[hondansx]

It works for me if I revert this changes.

Are all problems gone, if you revert these changes in vdr?

Marten

Yes.

[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

Code Select Expand

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...

Code Select Expand

--- 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?

[MartenR]

Yes I can, except that I also want a call to

Code Select Expand

lp->detachMVPReceiver();in the vompclient destructor.

Marten

[Uwe]

Hi,
That could be interesting...
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=29&t=19334

[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:

Code Select Expand

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:

Code Select Expand

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. 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