[MPlayer-dev-eng] [PATCH] TV auto scan and channel list in file

[Bernd Ernesti]

On Sat, Aug 25, 2007 at 06:06:08PM +0700, Vladimir Voroshilov wrote:
> 2007/8/25, Bernd Ernesti <mplayer-dev-eng at lists.veego.de>:
> > On Fri, Aug 24, 2007 at 12:19:04PM +0700, Vladimir Voroshilov wrote:
> 
> > Hmm, it seems to scan the channels.
> > I had to fix compile problems and made some format changes to make it more
> > readable.
> 
> Thanks.
> 
> > BUT, it always scans the channels even when I don't use -tvscan (just
> > mplayer tv://1).
> 
> It should not start scanning even you pass -tvscan option.
> Only "-tvscan autostart" starts scanning after MPlayer startup.

I know, but for me a scan is always issued while using the tv mode.
What I don't understand the tvh->tv_param->scan handling and why we need
it in so many places. 
Maybe you forget to add some tvh->tv_param->scan=0; protection lines.

One problem is in cfg-mplayer.h. See attached patch. This is needed so a
.mplayer/config entry would work with the tvscan options (e.g. tvscan=autostart=0)

But this doesn't fix the default autostart mode for me.

The tv_start_scan code path was not used because the "start scan" output didn't
happen.

> > Btw, tvi_bsdbt848.c needs some cleanup because it wasn't using mp_msg
> > before your patch. A lot of perror remains in it, which has to be fixed
> > in another run.
> 
> And a one big indentation patch ;)

Yeah, more in the other thread, after my autostart problem is fixed.

> > > I want to see printed value for active and inactive channels.
> 
> > - inactive
> > tvi_bt848: get signal 0x4
> > - active
> > tvi_bt848: get signal 0x2
> 
> This is VERY strange.
> All code i found uses this value as signal strength.
> I this case:
> 0x2=29%
> 0x4=57%
> Are you sure that inactive channel shows 0x4 rather than 0x2?
> Please recheck this once again to be sure

Yes, I'm sure. This maybe a difference how the signal value is set on
linux and the real meaning of the registers.

On linux (from drivers/media/video/bt8xx/bttv-driver.c):
  if (btread(BT848_DSTATUS)&BT848_DSTATUS_HLOC)
      t->signal = 0xffff;

So, signal is always set to 0xffff for a bt8xx device and most other devices too.
The exception which I could find was in the radio part of the saa7134 driver.

The real meaning for the bt8xx bits:

Device Status Register
Memory Mapped Location 0x000  (DSTATUS)
Upon reset it is initialized to 0x00. COF is the LSB. The COF and LOF status bits hold their values until reset to their
default values by writing to them. The other six bits do not hold their values, but continually output the status.
 Bits Name  Description
[..]

[6] HLOC    Device in H-lock. If HSYNC is found within ¡Þ1 clock cycle of the
             expected position of HSYNC for 32 consecutive lines, this bit is set
             to a logical 1. Once set, if HSYNC is not found within ¡Þ1 clock cycle
             of the expected position of HSYNC for 32 consecutive lines, this bit
             is set to a logical 0. Writes to this bit are ignored. This bit indicates
             the stability of the incoming video. While it is an indicator of hori-
             zontal locking, some video sources will characteristically vary from
             line to line by more than one clock cycle so this bit will never be
             set.
                 0      = Device not in H-lock.
                 1      = Device in H-lock.
[..]

[2] PLOCK  A logical 1 indicates the PLL is out of lock. Once s/w has initialized
            the PLL to run at the desired frequency, this bit should be read and
            cleared until it is no longer set (up to 100 ms). Then the clock input
            mode should be switched from xtal to PLL.
[1] LOF    Luma ADC Overow. On power-up, this bit is set to 0. If an ADC
            overow occurs, the bit is set to a logical 1. It is reset after being
            written to or a chip reset occurs.
[0] COF    Chroma ADC Overow. On power-up, this bit is set to 0. If an ADC
            overow occurs, the bit is set to a logical 1. It is reset after being
            written to or a chip reset occurs.


I changed the mp_msg to include the complette status and got that
for inactvice channels:
 tvi_bt848: get signal 0x7c 
 tvi_bt848: get signal 0x6c 

while this is for active channels:
 tvi_bt848: get signal 0x6a 

> If 0x4 corresponds to active channel, you can change line
>  *(int*)arg = status & 0x07?100:0;
> to
>  *(int*)arg = 100.0*(status & 0x07)/7;
> 
> to finally fix channel scanning for BT848

*(int*)arg = status & 0x02 ? 100 : 0;

works for me.

Regards,
Bernd

-------------- next part --------------
Index: cfg-mplayer.h
===================================================================
--- cfg-mplayer.h	(revision 24154)
+++ cfg-mplayer.h	(working copy)
@@ -396,7 +396,7 @@
 	{"nomouse-movements", &enable_mouse_movements, CONF_TYPE_FLAG, CONF_GLOBAL, 1, 0, NULL},
 	{"doubleclick-time", &doubleclick_time, CONF_TYPE_INT, CONF_RANGE, 0, 1000, NULL},
 #ifdef USE_TV
-	{"tvscan", &tvscan_conf, CONF_TYPE_SUBCONFIG, 0, 0, 0, NULL},
+	{"tvscan", tvscan_conf, CONF_TYPE_SUBCONFIG, 0, 0, 0, NULL},
 #else
 	{"tvscan", "MPlayer was compiled without TV interface support.\n", CONF_TYPE_PRINT, 0, 0, 0, NULL},
 #endif