headers
Mauro Carvalho Chehab | 1 Feb 2006 03:38
Picon
Favicon

Re: Proposal: add a new V4L2_STD_NTSC_M_KR standard

Em Dom, 2006-01-29 às 12:31 +0100, Hans Verkuil escreveu:
> Both the cx25840 and the msp3400 chips have support for the South-Korean 
> audio standard (which is the A2 standard, although Korea uses NTSC for 
> video). Unfortunately, it is currently not possible to select that 
> particular standard. It is ONLY used in Korea, and as such is very 
> similar to V4L2_STD_NTSC_M_JP which is only used in Japan.
> 
> I propose that this is added to the list of available standards allowing 
> proper support for this country.
> 
> Comments?
> 
> 	Hans

Acked-by: Mauro Carvalho Chehab <mauro_chehab <at> yahoo.com.br>

	

	
		
_______________________________________________________ 
Yahoo! doce lar. Faça do Yahoo! sua homepage. 
http://br.yahoo.com/homepageset.html 

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request <at> redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mike Baikov | 1 Feb 2006 07:24

Re: [SAA7134] Sound from TV directly over PCI bus (saa7134-alsa?)

Uros Vampl wrote:
> On 1/31/06, Michail Baikov <lists <at> baikov.com> wrote:
>   
>> Subj. Is possible?
>>
>> I has been try get TV sound w/o cables...
>> Now, only "sox DSP redirect" was help me, but it's not very beauty  :-(
>>
>> I'm using TVTime+SOX for now, because
>> My internal soundcard has been /dev/dsp
>> My second soundcatd has been /dev/dsp1 (not using now)
>> My "TV soundcard" [saa7134 oss=1 alsa=1] has been /dev/dsp2
>>
>> Anybody know more WORK (and beauty) methods?
>>
>>     
>
> MPlayer can get audio over the PCI bus. Check the v4l wiki entry for
> the Terratec Cinergy 400 Mobile on how to use it (adjust 'adevice' to
> suit your configuration):
>
> http://www.linuxtv.org/v4lwiki/index.php/Terratec_Cinergy_400TV_mobile#Viewers
>
> Regards,
> Uros
>
> --
> video4linux-list mailing list
> Unsubscribe mailto:video4linux-list-request <at> redhat.com?subject=unsubscribe
> https://www.redhat.com/mailman/listinfo/video4linux-list
(Continue reading)

Permalink | Reply | 4 comments |
headers
Ian Pickworth | 1 Feb 2006 09:08
Picon

Re: [SAA7134] Sound from TV directly over PCI bus (saa7134-alsa?)

Mike Baikov wrote:
> Uros Vampl wrote:
> 
>> On 1/31/06, Michail Baikov <lists <at> baikov.com> wrote:
>>  
>>
>>> Subj. Is possible?
>>>
>>> I has been try get TV sound w/o cables...
>>> Now, only "sox DSP redirect" was help me, but it's not very beauty  :-(
>>>
>>> I'm using TVTime+SOX for now, because
>>> My internal soundcard has been /dev/dsp
>>> My second soundcatd has been /dev/dsp1 (not using now)
>>> My "TV soundcard" [saa7134 oss=1 alsa=1] has been /dev/dsp2
>>>
>>> Anybody know more WORK (and beauty) methods?
>>>
>>>     
>>
>>
>> MPlayer can get audio over the PCI bus. Check the v4l wiki entry for
>> the Terratec Cinergy 400 Mobile on how to use it (adjust 'adevice' to
>> suit your configuration):
>>
>> http://www.linuxtv.org/v4lwiki/index.php/Terratec_Cinergy_400TV_mobile#Viewers 
>>
>>
>> Regards,
>> Uros
(Continue reading)

Permalink | Reply | 3 comments |
headers
Michael Schimek | 1 Feb 2006 16:33
Picon
Picon

Re: Proposal for improving handling of audmode (VIDIOC_S_TUNER)

On Wed, 2006-02-01 at 00:31 +0100, Hans Verkuil wrote:
> NICAM is digital, not analog. The analog carrier you refer to is just 
> the old mono carrier available in all TV standards.

Of course. Because LANG1/LANG2 refer to the digital carrier if present.

> Separating mono/stereo from lang1/lang2/lang3 is not a good idea because 
> it does not map to the way audio is transmitted. Mono always refers to 
> the mono subcarrier.

Except when NICAM is present MODE_MONO selects digital mono or digital
L+R. No mode explicitely selects the analog mono carrier.

> My proposal also has the advantage that application level changes are 
> limited (none in fact for most applications).

The MODE_STEREO change affects all V4L2 apps which can record in stereo,
and through v4l1-compat.c also V4L apps. I don't know if we can upset
enough users to form an angry mob with pitch forks and torches by
disabling old style bilingual recording in drivers which support it, but
if MODE_LANG1 already does what you want, why not wait until everyone
picked up LANG1_LANG2 and V4L is gone? Or deprecate MODE_STEREO and
define a new V4L2_TUNER_AUDMODE_STEREO = MODE_LANG1.

You didn't write if LANG1_LANG2 should cover mono/SAP and L+R/SAP as
well.

V4L2_TUNER_CAP_SAP is still ambiguous. Ideas?

Michael
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michel Bardiaux | 1 Feb 2006 16:59
Picon

Hauppauge WinTV Express 44809/E1A5

After ordering more of the cards that do work, as usual, we were sent a 
batch of gremlins:

Box # 0755, WinTV-Express

Sticker on tuner: 44809 rev E1A5

Under that sticker, another one:

MPE05-2
TCL050601_0_2

Here is dmesg:
becsrc{root} 80 # dmesg | grep bttv
bttv: driver version 0.7.108 loaded
bttv: using 2 buffers with 2080k (4160k total) for capture
bttv: Bt8xx card found (0).
bttv0: Bt878 (rev 17) at 04:02.0, irq: 18, latency: 64, mmio: 0xf0001000
bttv0: detected: Hauppauge WinTV [card=10], PCI subsystem ID is 0070:13eb
bttv0: using: Hauppauge (bt878) [card=10,autodetected]
bttv0: Hauppauge/Voodoo msp34xx: reset line init [5]
bttv0: Hauppauge eeprom: model=29440, tuner=<NULL> (-1), radio=no
bttv0: using tuner=38
                    ^^^^ we were trying to force that
bttv0: i2c: checking for MSP34xx  <at>  0x80... not found
bttv0: i2c: checking for TDA9875  <at>  0xb0... not found
bttv0: i2c: checking for TDA7432  <at>  0x8a... not found
bttv0: PLL: 28636363 => 35468950 .. ok
bttv0: registered device video0
bttv0: registered device vbi0
(Continue reading)

Permalink | Reply | 4 comments |
headers
Steve Toth | 1 Feb 2006 20:00
Favicon

Re: wintv nova-s-plus linux diseqc support

Hi,
> I would like to know what the timeframe is for implementing diseqc
> support in the wintv nova-s-plus linux driver.
>
> As of today's (Feb 1) v4l-dvb merged tree, any diseqc command to the
> driver outputs a message saying that "diseqc not yet supported".
>
>   
Right now, it has no priority. With the limited time I have I'm working 
on another GPL driver.

The datasheets for all of the registers are public, if you would like to 
contribute to development, your patches would be most welcome :)

Regards,

Steve

_______________________________________________
linux-dvb mailing list
linux-dvb <at> linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Permalink | Reply | 2 comments |
headers
Graham Finlayson | 1 Feb 2006 20:37

Re: DViCo PCI Dual-T USB Problem

Michael Krufky wrote:
> Graham Finlayson wrote:
> 
>> Which shows to me that the working dvbscan started more USB feeds (?)
>> than the non-working dvbscan. I don't know what controls the number of
>> these that are started, but I am trying to track that down at the
>> moment, to see if this is just a timing issue, or whether there is
>> something else that causes it.
>>
>> The only other dubious looking events in the debug log are of the form
>>  
>>
> I'm sorry I didnt respond to your previous email -- been very busy.  You
> get an oops if you unplug the device while it is still in use.  I was
> suggesting that you unplug and re-plug after you discontinued operation.
> 
> Anyhow, I'm not sure what the problem is that you're having... mythtv is
> too large a variable for me to deal with...  For testing, I usually use
> atscscan + azap + mplayer.... In your case, you should use dvbscan +
> tzap + mplayer.
> 
> I wrote up a quick howto for testing, using ATSC standards... I suggest
> that you conduct your test following the instructions in this howto, but
> replace every occurrance of atsc with dvb-t, replace atscscan with
> dvbscan, and replace azap with tzap.
> 
> http://linuxtv.org/~mkrufky/atscscan/
> 
>> "i2c read could have been failed" and "i2c write could have been failed"
>>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Hugo González Monteverde | 1 Feb 2006 21:01

Lifeview 3000 (unsupported tuner, complete description)

Hi Gunther and all,

Finally I was able to take pictures of the card and box contents. I have
uploaded hi-res pictures to http://www.h-lab.net/v4l/ They're big files,
and the filenames are descriptive. Pretty much everything can be seen.

I uploaded the PDF manual and the INF file from the Windows installation
disc too.

Gunther Mayer wrote:
> Hi,
> can you send me a picture of your card and further info for inclusion to
> http://www.bttv-gallery.de ?

I hope they are useful for the gallery. I can resize them if you want as
they're very big files.
> 
> Your contribution will help to improve open source support!
> Because there are many cards and variations by different
> vendors, the developers need _your_ help to get it all supported.
> 
> 1st priority:
> - picture of the card, the card backside (high resolution pics if feasible)
done

> - lspci -vn

This is what is reported for the card. I did not want to include every 
other peripheral, but for the record, it is in the file diag.txt in the 
same location with the images.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Patrick Boettcher | 1 Feb 2006 21:11
Picon
Favicon

Re: DViCo PCI Dual-T USB Problem

On Wed, 1 Feb 2006, Graham Finlayson wrote:

> Feb  1 19:26:00 mythtv start pid: 0x00ca, feedtype: 0
> Feb  1 19:26:00 mythtv setting pid:   202 00ca at index 1 'on'
> Feb  1 19:26:00 mythtv 'bulk' urb completed. feedcount: 2, status: 0,
> length: 8192/8192, pack_num: 0, errors: 0
> Feb  1 19:26:00 mythtv Demux Buf Length : 0 Demux Buf[0] : 47 PID : 5481
> Feb  1 19:26:00 mythtv 'bulk' urb completed. feedcount: 2, status: 0,
> length: 8192/8192, pack_num: 0, errors: 0
> Feb  1 19:26:00 mythtv Demux Buf Length : 119 Demux Buf[0] : 47 PID : 4117
> Feb  1 19:26:00 mythtv 'bulk' urb completed. feedcount: 2, status: 0,
> length: 8192/8192, pack_num: 0, errors: 0
> Feb  1 19:26:00 mythtv Demux Buf Length : 0 Demux Buf[0] : 47 PID : 4117
> [...]
> which if you look closely has some very bad PID information!!! THis
> causes the demuxer to not be able to separate the PID streams, and so
> things don't work very well.

What makes you thinking that?

The bluebird and most of the other USB2.0 cars, do not have a PID filter 
in hardware, i.e. when you start requesting data you will always get the 
whole Transport Stream containing all Packets with all PIDs. That's why 
the PIDs you not requested (Is it that what confuses you?

I have no idea why mplayer is not working correctly the first time and 
your other problems, but from the log you just provided everything seems 
to be OK.

The only thing which makes me think a little is, that each returning
(Continue reading)

Permalink | Reply | 0 comments |
headers
Johannes Stezenbach | 2 Feb 2006 01:24

DVB and V4L Wiki update

Hi all,

I've updated the DVB and V4L Wiki software from MediaWiki-1.4.12
to MediaWiki-1.5.6.

If you experience any problems with
the Wikis, please let me know about it.

Johannes

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request <at> redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
Permalink | Reply | 0 comments |

Gmane