Ah, need to do this actually, for the time being...

  modprobe ivtv ivtv_std=2

This should allow alot of logic in the ivtv driver itself to work for PAL/NTSC
switching, which has never really been active because we have alot of logic
well before the autodetection which checks the tv standard.  Also the digitizer
startup can be given the tv standard this way, otherwise we don't know the
tv standard yet.  It was always 'assumed' the ivtv drvier defaulted to NTSC
settings and PAL would either be set or autodetected, but oddly it just didn't
do that or autodetect smoothly.  This change was mainly for the YUV buffers
size checks, the VBI buffer and line size checks (for some reason we need this
extra bit in CC else we miss characters, it's odd, but seems to be a problem),
and also I force the digitizer cx25840 now into NTSC audio manually instead
of autodetect mode, so it needs to know the tv standard in the digitizer,
and that is set now from the ivtv module from it knowing the standard from
the startup when it sets up things like the digitizer.  It needs work and is
more of an invitation and example of where we need to do the work to get
the digitizer setup improved and module standard properly detected early
on instead of later, and get things to work as expected.  I think the
cx25840 part is not right yet, but was a quick way to get audio to be setup
properly for NTSC and give a path for PAL to do the same thing (didn't know
the value for PAL or totally how we need to check and set the audio register).


So it's good to use that module option, I always expected it to be used by
people using PAL since that's how it originally was, but I think autodetection
support was implemented and no one looked closely to see if it was really
totally 'right', and seems it has pitfals which may need some major logic
overhaul to make it allow decisions to be made upon the tv standard early
in module load.


Thanks,
Chris
On Sun, May 22, 2005 at 10:24:33AM +0200, Sigurd Nes wrote:
> The sound is very poor in 0.3.5.c compared to 0.3.5
> I have not tested 0.3.5.b
> I live in a PAL–country, is the the black_magic stuff related to this?
> 
> Regards
> 
> Sigurd
> 
> Chris Kennedy wrote:
> >This should fix a couple problems with YUV decoding, especially 
> >/dev/video48,
> >now works really nice (uses the vsync interrupt).  Also I think the alias
> >oddity of the other field seen for NTSC is now fixed.  It also fixes Myth
> >ff/rw over 3x speed image not advancing, I *think*, please test and see.
> >
> >#0.3.5c: http://www.ivtv.tv/releases/ivtv-0.3/
> >
> >Thanks,
> >Chris
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
> _______________________________________________
> ivtv-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/ivtv-devel

-- 
---
 Chris Kennedy / [EMAIL PROTECTED]
  Engineer KMOS-TV/KTBG-FM
  Broadcasting Services Department
  Central Missouri State University


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_idt12&alloc_id344&op=click
_______________________________________________
ivtv-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ivtv-devel

Reply via email to