[MPlayer-users] How to tell if the video input is interlaced or not?

[Jouni.Lohikoski@iki.fi]

On Thu, Dec 15, 2005 at 04:47:07PM -0800, RC wrote:
> It only works without X?  That really doesn't make any sense to me.  I
> can't think of any reason a capture card would stop working when X
> starts.

Something to do with DMA access and how they changed xv driver from old
XFree86 to Xorg's current one. It just do not work if X has been even
visited during the boot session.
See:
http://sourceforge.net/mailarchive/forum.php?thread_id=9003225&forum_id=34082

> > I am able to watch video input in a concole with:
> > mplayer -vo vesa -tv
> > driver=v4l:norm=PAL:input=0:outfmt=uyvy:width=704:height=576:fps=50
> > tv://
> 
> fps=50?  The F in fps means frames not fields, so that should be fps=25.
>  You're just wasting CPU time doing that, AFAIK.

Hmm...ok. I thought if the card would provide de-interlaced frames at
that speed. The "2nd" field from PAL is "time stamped" later than the
1st field, so there could be 50 different frames in every second.
Correct me if I am wrong.

Doesn't the FPS in the -tv options mean how many "images" it gets from
the capture device+driver per second?

> I think you can safely assume (PAL) TV is always going to be
> interlaced.

Also assume same for any PAL capture card?
And as the driver/chip can output 576 lines, why cannot I assume it does
de-interlacing itself?

And if I then capture 288 lines (height) 50 times in second, I should
deinterlace by mplayer and somehow convert it to from 50 fields per sec
to 25 FPS?

As I understand it, in PAL, there is 50 fields 704x288 per second, every
other field has lines shifted one vertical line down interlacing with
the first field. But what output comes from the capture chip is a
mystery, even after reading "tv-input.html" and testing abit around.

In tv-input.html:
"If you capture the video with the vertical resolution higher than half
of the full resolution (i.e. 288 for PAL or 240 for NTSC), make sure you
turned deinterlacing on. "

The above quote isn't quite clear. Why if the capture-chip and the
driver already provides 704x576 "images" to the application, 
they should be deinterlaced?