All of lore.kernel.org
 help / color / mirror / Atom feed
* NTSC_443 problem in v4l and em28x
@ 2012-04-02 21:02 Colin Eby
  2012-04-02 21:25 ` Devin Heitmueller
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: Colin Eby @ 2012-04-02 21:02 UTC (permalink / raw)
  To: linux-media

All, 

Wondered if someone could advise... I'm from an NTSC and PAL capable
tape deck, in the UK. I believe that means the signal coming from the
deck will be NTSC_443 compliant. What is captured through VLC or XAWTV
is slightly grainy black and white (no green band). It kinda looks like
the there are no capture distinctions between NTSC_443 and NTSC. I'd try
tweaking the code around this, but I'm not clear where it's controlled
from. Can someone help guide me?  I have a mountain of these tapes to
capture for a museum.

Here's the setup:
U-matic Sony VO5630 VTR using BNC to RCA video out
V4L2 device Pinnacle Dazzle DVC 90/100/101/ using driver: em28xx
(version: 0.1.2) 
Fedora 14
VLC 1.1.12

I know about the issue with changing video standards in this VLC UI
version. That's not the problem, and I've confirmed it with a slightly
more up to date Ubuntu equivalent.  I get the same behaviour in XAWTV
and VLC. Here's some of what my experimentation has shown.

* On PAL tapes this gear works fine (with the deck switched to PAL and
VLC set to PAL)
* Direct to TV the gear works fine in NTSC mode (bless modern flat
panels)
* Using Windows and AmCap I get colour video on the NTSC tapes. __The
setting that work there is NTSC_443 with a YUYV colour space.__
* I've tried all the different standards available in VLC and XAWTV with
the deck set to NTSC and an NTSC tape. I see no visible difference
between NTSC, NTSC_M or NTSC_443 -- and based on work in Windows, I
believe I should.
* Debug from V4L/VLC shows NTSC_443 is supported in the driver.

There's clear evidence I can get some kind of tool chain to work in
Windows. But I wondered if there wasn't some fine tuning to the driver
that would get Linux rig to work.  And I wondered if there were known
issues around the NTSC_443 norm. Forgive me if I've missed any, but I
haven't found any so far.

-- Colin


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: NTSC_443 problem in v4l and em28x
  2012-04-02 21:02 NTSC_443 problem in v4l and em28x Colin Eby
@ 2012-04-02 21:25 ` Devin Heitmueller
  2012-04-02 21:30 ` Devin Heitmueller
  2012-04-03  3:01 ` Andy Walls
  2 siblings, 0 replies; 4+ messages in thread
From: Devin Heitmueller @ 2012-04-02 21:25 UTC (permalink / raw)
  To: colineby; +Cc: linux-media

On Mon, Apr 2, 2012 at 5:02 PM, Colin Eby <colineby@isallthat.com> wrote:
> There's clear evidence I can get some kind of tool chain to work in
> Windows. But I wondered if there wasn't some fine tuning to the driver
> that would get Linux rig to work.  And I wondered if there were known
> issues around the NTSC_443 norm. Forgive me if I've missed any, but I
> haven't found any so far.

I've done a bunch of work on that driver, and the answer is probably
really simple - 443 is so rare that none of the developers has the
playback hardware to test with.  I'm not even sure my analog signal
generator will output the format.

Unfortunately, until some developer needs it to work and has the time
to debug it, you're probably out of luck.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: NTSC_443 problem in v4l and em28x
  2012-04-02 21:02 NTSC_443 problem in v4l and em28x Colin Eby
  2012-04-02 21:25 ` Devin Heitmueller
@ 2012-04-02 21:30 ` Devin Heitmueller
  2012-04-03  3:01 ` Andy Walls
  2 siblings, 0 replies; 4+ messages in thread
From: Devin Heitmueller @ 2012-04-02 21:30 UTC (permalink / raw)
  To: colineby; +Cc: linux-media

On Mon, Apr 2, 2012 at 5:02 PM, Colin Eby <colineby@isallthat.com> wrote:
> There's clear evidence I can get some kind of tool chain to work in
> Windows. But I wondered if there wasn't some fine tuning to the driver
> that would get Linux rig to work.  And I wondered if there were known
> issues around the NTSC_443 norm. Forgive me if I've missed any, but I
> haven't found any so far.

It's probably also worth mentioning that if you want to try to debug
this yourself, the problem is probably in the saa711x driver (the
video decoder chip in the Dazzle), not the em28xx driver.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: NTSC_443 problem in v4l and em28x
  2012-04-02 21:02 NTSC_443 problem in v4l and em28x Colin Eby
  2012-04-02 21:25 ` Devin Heitmueller
  2012-04-02 21:30 ` Devin Heitmueller
@ 2012-04-03  3:01 ` Andy Walls
  2 siblings, 0 replies; 4+ messages in thread
From: Andy Walls @ 2012-04-03  3:01 UTC (permalink / raw)
  To: colineby, linux-media

Colin Eby <colineby@isallthat.com> wrote:

>All, 
>
>Wondered if someone could advise... I'm from an NTSC and PAL capable
>tape deck, in the UK. I believe that means the signal coming from the
>deck will be NTSC_443 compliant. What is captured through VLC or XAWTV
>is slightly grainy black and white (no green band). It kinda looks like
>the there are no capture distinctions between NTSC_443 and NTSC. I'd
>try
>tweaking the code around this, but I'm not clear where it's controlled
>from. Can someone help guide me?  I have a mountain of these tapes to
>capture for a museum.
>
>Here's the setup:
>U-matic Sony VO5630 VTR using BNC to RCA video out
>V4L2 device Pinnacle Dazzle DVC 90/100/101/ using driver: em28xx
>(version: 0.1.2) 
>Fedora 14
>VLC 1.1.12
>
>I know about the issue with changing video standards in this VLC UI
>version. That's not the problem, and I've confirmed it with a slightly
>more up to date Ubuntu equivalent.  I get the same behaviour in XAWTV
>and VLC. Here's some of what my experimentation has shown.
>
>* On PAL tapes this gear works fine (with the deck switched to PAL and
>VLC set to PAL)
>* Direct to TV the gear works fine in NTSC mode (bless modern flat
>panels)
>* Using Windows and AmCap I get colour video on the NTSC tapes. __The
>setting that work there is NTSC_443 with a YUYV colour space.__
>* I've tried all the different standards available in VLC and XAWTV
>with
>the deck set to NTSC and an NTSC tape. I see no visible difference
>between NTSC, NTSC_M or NTSC_443 -- and based on work in Windows, I
>believe I should.
>* Debug from V4L/VLC shows NTSC_443 is supported in the driver.
>
>There's clear evidence I can get some kind of tool chain to work in
>Windows. But I wondered if there wasn't some fine tuning to the driver
>that would get Linux rig to work.  And I wondered if there were known
>issues around the NTSC_443 norm. Forgive me if I've missed any, but I
>haven't found any so far.
>
>-- Colin
>
>--
>To unsubscribe from this list: send the line "unsubscribe linux-media"
>in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html

Well the tape deck does output NTSC 4.43:
http://umatic.palsite.com/vo5630spec.shtml

The horizontal line count seems unusual.

Anyway, Devin is right, NTSC 4.43 is really rare.

My first bit of advice is to ensure the video input is set specifically to NTSC_443, and no other NTSC, PAL, or SECAM standard using v4l2-ctl on the /dev/videoN node.  No chip is likely ever going to autodetect NTSC 4.43 properly (under linux at least).

The CX2584x chips supposedly handle NTSC 4.43.  If you have a PVR-150 card lying around, maybe that will work better.

Regards,
Andy

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2012-04-03  3:01 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-04-02 21:02 NTSC_443 problem in v4l and em28x Colin Eby
2012-04-02 21:25 ` Devin Heitmueller
2012-04-02 21:30 ` Devin Heitmueller
2012-04-03  3:01 ` Andy Walls

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.