Re: Brazilian television capture device

[David Liontooth]

On 10/20/15 11:32 AM, Markus Rechberger wrote:

The new Sundtek devices support DVB-C, DVB-T, ISDB-T, AnalogTV and FM Radio.
The old ones only supported ISDB-T/AnalogTV and FM Radio.
Power consumption is very low too.
OK, very cool -- I see for instance 
http://sundtek.com/shop/Digital-TV-Sticks-oxid/Sundtek-MediaTV-ISDB-T-ISDB-T/DVB-C-FM-Radio-AnalogTV.html


Page claims "Linux and FreeBSD Support".

Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Brazilian television capture device

[David Liontooth]

Does anyone know of a tv capture device for Brazil (ISDB-T) that is 
supported in Linux and available for sale?


I'm having a hard time finding any of the devices listed under 
http://www.linuxtv.org/wiki/index.php/ISDB-T_USB_Devices or ISDB-T PCIe 
devices --


* Pixelview SBTVD 
(http://www.kabum.com.br/produto/6784/receptor-de-tv-digital-pixelview-playtv-usb-2-0-sbtvd-full-seg-pv-d231urn-f) 
is out of stock
* Geniatech/MyGica X8507 PCI-Express Hybrid Card 
(http://www.linuxtv.org/wiki/index.php/Geniatech/MyGica_X8507_PCI-Express_Hybrid_Card)


I see the Aver3d Hybrid Volar Xpro (H869 -- 
http://avertv.avermedia.com/avertv/Upload/ProductImages/DS_H869_EN_140415.pdf) 
at americanas.com 
(http://www.americanas.com.br/produto/9869979/placa-captura-de-tv-aver3d-hybrid-volar-xpro) 
-- is it supported?


I'm advising friends remotely, so I can't just purchase it and try it out.

Cheers,
Dave

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: dvbv5-scan needs which channel file?

[David Liontooth]

OK, perfect; thank you. This should be documented in dvbv5-scan. And we 
should have a man page for it.


Cheers,
David

On 12/30/14, 5:15 AM, Olli Salonen wrote:

Hi David,

Well, the initial scan files need to be supplied for dvbv5-scan somehow.

The initial scan files that are maintained in the the git repo I
posted earlier are updated by users who notice differencies. Basically
I and some other users have created scripts that automatically
generate the files for my country, so it's rather easy. I don't know
how it works for other countries.

Anyway, if you prefer to generate the data yourself you can use w_scan
to generate it in DVBV3 format:
w_scan -ft -c FI -x > ~/initial_v3.conf

Then use the dvb-format-convert tool that comes in the v4l-utils package:
dvb-format-convert -I CHANNEL -O DVBV5 ~/initial_v3.conf ~/initial_data_v5.conf

Then you can run dvbv5-scan with this file:
dvbv5-scan ~/initial_data_v5.conf

Alternatively you can skip the whole conversion phase and run
dvbv5-scan with the DVBV3 initial tuning data:
dvbv5-scan -I CHANNEL ~/initial_v3.conf

Cheers,
-olli

On 30 December 2014 at 10:23, David Liontooth  wrote:

Ah, thank you Olli -- much appreciated!

If dvbv5-scan expects the initial scan files in the new DVBV5 format, does
that mean that these still somewhat mysterious "initial scan files" have to
be supplied, as in the link to the dtv-scan-tables? How are these "initial
scan files" themselves generated?

Surely there must be thousands of different dvb signal locations -- is
linux-tv going to try to maintain these thousands of scan tables for
download? What do users do when their particular location is not represented
in the dtv-scan-tables.git?

Finally, I'm using gnutv to record television; I imagine it still only
accepts the old format? What's the new alternative?

Cheers,
David

On 12/29/14, 11:55 PM, Olli Salonen wrote:

Hello David,

Coincidentally I was just yesterday working with dvbv5-scan and the
initial scan files. dvbv5-scan expects the initial scan files in the
new DVBV5 format. w_scan is not producing results in this format.

The scan tables at
http://git.linuxtv.org/cgit.cgi/dtv-scan-tables.git/ are in the new
format. Some of them are a bit outdated though (send in a patch if you
can update it for your area).

The v4l-utils package also includes tools to convert between the old
and the new format.

Cheers,
-olli


On 29 December 2014 at 22:09, David Liontooth 
wrote:

Greetings --

How do you actually use dvbv5-scan? It seems to require some kind of
input
file but there is no man page and the --help screen doesn't say anything
about it.

Could we document this? I tried

$ dvbv5-scan
Usage: dvbv5-scan [OPTION...] 
scan DVB services using the channel file

What is "the channel file"? Maybe the channels.conf file? (I created mine
using "w_scan -ft -A3 -X -cUS -o7 -a /dev/dvb/adapter0/")

$ dvbv5-scan /etc/channels.conf
ERROR key/value without a channel group while parsing line 1 of
/etc/channels.conf

So it knows what it wants -- but what is it? Or is this a matter of dvb
versions, and my /etc/channels.conf is in the older format?

Very mysterious.

Cheers,
David
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html



--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: dvbv5-scan needs which channel file?

[David Liontooth]

Ah, thank you Olli -- much appreciated!

If dvbv5-scan expects the initial scan files in the new DVBV5 format, 
does that mean that these still somewhat mysterious "initial scan files" 
have to be supplied, as in the link to the dtv-scan-tables? How are 
these "initial scan files" themselves generated?


Surely there must be thousands of different dvb signal locations -- is 
linux-tv going to try to maintain these thousands of scan tables for 
download? What do users do when their particular location is not 
represented in the dtv-scan-tables.git?


Finally, I'm using gnutv to record television; I imagine it still only 
accepts the old format? What's the new alternative?


Cheers,
David

On 12/29/14, 11:55 PM, Olli Salonen wrote:

Hello David,

Coincidentally I was just yesterday working with dvbv5-scan and the
initial scan files. dvbv5-scan expects the initial scan files in the
new DVBV5 format. w_scan is not producing results in this format.

The scan tables at
http://git.linuxtv.org/cgit.cgi/dtv-scan-tables.git/ are in the new
format. Some of them are a bit outdated though (send in a patch if you
can update it for your area).

The v4l-utils package also includes tools to convert between the old
and the new format.

Cheers,
-olli


On 29 December 2014 at 22:09, David Liontooth  wrote:

Greetings --

How do you actually use dvbv5-scan? It seems to require some kind of input
file but there is no man page and the --help screen doesn't say anything
about it.

Could we document this? I tried

$ dvbv5-scan
Usage: dvbv5-scan [OPTION...] 
scan DVB services using the channel file

What is "the channel file"? Maybe the channels.conf file? (I created mine
using "w_scan -ft -A3 -X -cUS -o7 -a /dev/dvb/adapter0/")

$ dvbv5-scan /etc/channels.conf
ERROR key/value without a channel group while parsing line 1 of
/etc/channels.conf

So it knows what it wants -- but what is it? Or is this a matter of dvb
versions, and my /etc/channels.conf is in the older format?

Very mysterious.

Cheers,
David
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

dvbv5-scan needs which channel file?

[David Liontooth]

Greetings --

How do you actually use dvbv5-scan? It seems to require some kind of 
input file but there is no man page and the --help screen doesn't say 
anything about it.


Could we document this? I tried

$ dvbv5-scan
Usage: dvbv5-scan [OPTION...] 
scan DVB services using the channel file

What is "the channel file"? Maybe the channels.conf file? (I created 
mine using "w_scan -ft -A3 -X -cUS -o7 -a /dev/dvb/adapter0/")


$ dvbv5-scan /etc/channels.conf
ERROR key/value without a channel group while parsing line 1 of 
/etc/channels.conf


So it knows what it wants -- but what is it? Or is this a matter of dvb 
versions, and my /etc/channels.conf is in the older format?


Very mysterious.

Cheers,
David
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ISDB caption support

[David Liontooth]

Hi Devin,

Great, thanks.

I realize captions is an application-layer function, and intend to work 
with the CCExtractor team. Do any other applications already have ISDB 
caption support?


For DVB and ATSC there's quite a bit of code written by several people 
for teletext and captions -- has anything at all been done for ISDB 
captions?


It's used in nearly all of Central and South America, plus the 
Philippines and of course Japan -- you would have thought someone has 
started on the task?


We're looking for a good solution for capturing television in Brazil, 
when the signal is encrypted -- are there set-top boxes or tv capture 
cards that handle the decryption so that the decoded signal is passed on 
with the ISDB-Tb caption stream intact?


Our test system generates captions as an overlay and does not pass on 
the closed captions.


Cheers,
David


On 11/28/14, 6:40 PM, Devin Heitmueller wrote:

Hi David,

ISDB-T subtitles are done in a similar manner to DVB-T subtitles -
there is a PID in the stream which contains the subtitle data, which
needs to be decoded by the application (just as you would handle DVB-T
subtitles or ATSC closed captions).  It's entirely an application
level function, having nothing to do with the driver layer.

In short, this has nothing to do with DVBv5, as that is all about how
the tuner is controlled, not what gets done with the resulting MPEG
stream.  You would need to talk to whoever is responsible for the
application you are working with (whether that be VLC, mplayer,
ccextractor, etc).

Cheers,

Devin

On Fri, Nov 28, 2014 at 2:55 PM, David Liontooth  wrote:

What is the status of ISDB-Tb / ISDB-T International / ISDB Japanese closed
captioning support?

If anyone is working on this, please get in touch -- we're particularly
interested in getting Brazilian SBTVD working.

I see Mauro has been working on DVBv5 support, but does this include
captioning?

Cheers,
David
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html





--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

ISDB caption support

[David Liontooth]

What is the status of ISDB-Tb / ISDB-T International / ISDB Japanese 
closed captioning support?


If anyone is working on this, please get in touch -- we're particularly 
interested in getting Brazilian SBTVD working.


I see Mauro has been working on DVBv5 support, but does this include 
captioning?


Cheers,
David
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Status of DVB-C cards with CI

[David Liontooth]

I'm trying to put together a box with DVB-C PCIe (or PCI) cards and CI 
support for recording in Denmark.


Is there support for any such cards in Linuxtv or mainline?

In Denmark, as I understand it, even the main national public station is 
encrypted, and as of January 2012 the transport stream is MPEG4.


NetUp's Dual DVB TC CI 
(http://www.netup.tv/en-EN/dual_dvb-t-c-ci_card.php) appears to have the 
features I'm looking for, but the driver is not in mainline. Are there 
other options?


Appreciate any suggestions!

David
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Unsafe to reinsert HVR-1850 kernel modules?

[David Liontooth]

On 11/29/2010 04:38 AM, Andy Walls wrote:

On Sun, 2010-11-28 at 23:49 -0800, David Liontooth wrote:

My HVR-1850 card  occasionally jams, meaning it still tunes (according
to gnutv), but no mpeg stream comes through.

This heals on reboot, but I figured it should also heal on module
reinsertion.

However, when I remove the CX23885 module, along with the full set of
DVB and related modules, and then reinsert them, I get this error when I
attempt to open the stream -- zvbi-atsc-cc will for instance trigger it:

kernel:do_IRQ: 5.82 No irq handler for vector (irq -1)

This happens when an initial "MSI Data" vector is assigned to the
CX23888 chip and written into its PCI config space, and then the kernel
assigns a new "MSI Data" vector for the CX23888 and writes the new "MSI
Data" vector into its PCI config space.  This is what happens at cx23885
module reload with MSI enabled on your system.

The CX2388[578] chips ignore the new "MSI Data" vector and continue to
use the first assigned one.  The kernel doesn't have an IRQ handler
function to call for the old vector anymore, so do_IRQ blurts out its
message.




If one card was initially jammed, now all the cards are jammed -- I'm
testing five cards at once.

They are all still trying to fire interrupts, just with the "wrong"
vector, so the kenrel ignores them.




A discussion at
http://www.mail-archive.com/linux-media@vger.kernel.org/msg22375.html
suggested adding the kernel parameter "pci=nommconf", but when I do that
the problem does not go away

For a quick band-aid, use "pci=nomsi" on your kernel command line, and
reboot to reset the CX23888 hardware.

The problem is MSI.  The cx23885 driver isn't ready for it.  The patch
that enabled MSI for cx23885 probably needs to be reverted until some of
these issues are sorted out.



  -- and I also got this (perhaps unrelated):

   cx25840 15-0044: likely a confused/unresponsive cx2388[578] A/V
decoder found @ 0x88 (cx23885[4])
   cx25840 15-0044: A method to reset it from the cx25840 driver software
is not known at this time

Is it currently not safe to remove and reinsert the kernel modules for
the HVR-1850, or am I just seeing a quirk?

This is unrelated.  This happens when the CX2388[578] A/V core device
probe fails to complete - usually due to a missing firmware file or some
other Linux cx23885 or cx25840 module unhappiness.  (Like the bug I
found and fixed just yesterday - see my latest GIT pull request.)

Once the CX2388[578] A/V core is in this state, it fails to respond to
reads over the internal I2C bus.  That makes it impossible for the
cx25840 module to interrogate the CX2388x A/V core and figure out which
type it is talking to, so that it can initialize it.

Testing last night indicates that, if the cx25840 module had apriori
knowledge of the type of A/V core, it could do the I2C writes anyway to
initialize the A/V core and bring it back to a somewhat working
condition.

Your only course of action right now is, again, a hardware reset to get
the CX2388[578] A/V core's I2C interface block back to a sane state.
Otherwise, IR and analog video will not work properly for you.
Thanks, Andy, that's very helpful. I wouldn't care that much about 
module reinsertion if it weren't for the fact that the HVR-1850 behaves 
in a very finicky way, jamming on the smallest pretext. That said, once 
I put the cards in a fully automated environment where they only get 
correct gnutv requests, they've been behaving well. If it's possible to 
modify the driver so reinsertion is possible, that would be a big help 
-- what do we lose by removing the MSI support patch?


Cheers,
Dave

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: gnutv: What causes DVR overflow?

[David Liontooth]

On 11/29/2010 05:24 AM, Devin Heitmueller wrote:

On Mon, Nov 29, 2010 at 2:54 AM, David Liontooth  wrote:

I'm seeing great results with gnutv on HVR-1850 cards, but each recording
triggers the message

  DVR overflow

What is this, and what are the typical causes? What can I do to prevent it
from happening?

I don't know about gnutv specifically, but I do know that -EOVERFLOW
is returned when an application fails to read the
/dev/dvb/adapterX/dvr0 device fast enough.  It's the driver signaling
to the application that it did not read the file handle often/fast
enough and that the driver is going to drop packets to keep up.

The driver has a limited amount of buffering, so if you have a delay
that is too long between read() calls (or your read buffer is too
small to accommodate the data rate) you will encounter this condition.
Thanks, Devin! On my end, it looks like the DVR overflow was caused by 
the -out file being on a mirrored OS drive; I've moved output to a 
separate drive and don't see the error any more. If I run into this 
again, are there ways to make this more robust -- for instance, increase 
the cache size, either as a parameter to the kernel module, or in gnutv?


Cheers,
Dave

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

gnutv: What causes DVR overflow?

[David Liontooth]

I'm seeing great results with gnutv on HVR-1850 cards, but each 
recording triggers the message


  DVR overflow

What is this, and what are the typical causes? What can I do to prevent 
it from happening?


Could it be related to slow hard drives?

I'm assuming an overflow results in some degree of corruption of the 
stream that I write to file.


Cheers,
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Unsafe to reinsert HVR-1850 kernel modules?

[David Liontooth]

My HVR-1850 card  occasionally jams, meaning it still tunes (according 
to gnutv), but no mpeg stream comes through.


This heals on reboot, but I figured it should also heal on module 
reinsertion.


However, when I remove the CX23885 module, along with the full set of 
DVB and related modules, and then reinsert them, I get this error when I 
attempt to open the stream -- zvbi-atsc-cc will for instance trigger it:


kernel:do_IRQ: 5.82 No irq handler for vector (irq -1)

If one card was initially jammed, now all the cards are jammed -- I'm 
testing five cards at once.


A discussion at 
http://www.mail-archive.com/linux-media@vger.kernel.org/msg22375.html 
suggested adding the kernel parameter "pci=nommconf", but when I do that 
the problem does not go away -- and I also got this (perhaps unrelated):


 cx25840 15-0044: likely a confused/unresponsive cx2388[578] A/V 
decoder found @ 0x88 (cx23885[4])
 cx25840 15-0044: A method to reset it from the cx25840 driver software 
is not known at this time


Is it currently not safe to remove and reinsert the kernel modules for 
the HVR-1850, or am I just seeing a quirk?


Cheers,
Dave


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-dvb] gnutv: move channel_name to flag to allow piped output

[David Liontooth]

On 11/28/2010 03:40 AM, Edgar Matzinger wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Dave,

On 28/11/10 05:42, David Liontooth wrote:


  gnutv -adapter 0 -channel_list ~/.azap/channels.conf -timeout 10
-channel_name  KCBS \
  -out stdout | tee $FIL.mpg | zvbi-atsc-cc --atsc -T -9 $FIL.txt -n KCBS


This should work:

$ gnutv -adapter 0 -channel_list ~/.azap/channels.conf -timeout 10 \

-out stdout KCBS | tee $FIL.mpg | zvbi-atsc-cc --atsc -T -9 $FIL.txt \
-n KCBS

Yes it does - I didn't think of trying that. Thanks to you and Oliver!


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

gnutv: move channel_name to flag to allow piped output

[David Liontooth]

I need to capture ATSC QAM closed captioning to file, and at the same 
time the mpeg-ts stream to a different file. I've been looking for an 
app that will let me do this.


A simple cat works:

 cat /dev/dvb/adapter0/dvr0 | tee $FIL.mpg | zvbi-atsc-cc --atsc -m -C 
$FIL.txt -T KCBS


But there is naturally no tuner or timer in cat, so closing the 
processes at the end of the recording is a hassle; there may be other 
issues cat doesn't handle optimally. I looked around and found gnutv in 
the dvb-apps project.


gnutv is actively maintained, tunes ATSC QAM-256, handles individual 
channels well, and has a timer -- but it has a small, show-stopper problem.


gnutv mandates that the channel name be placed at the end of the user 
input. There is a great -out stdout option, but you can't use it to 
pipe, since the channel name has to be placed afterwards.


I suggest we move the channel name into a flag, like the other user 
values, so that we can pipe the output like this:


 gnutv -adapter 0 -channel_list ~/.azap/channels.conf -timeout 10 
-channel_name  KCBS \

 -out stdout | tee $FIL.mpg | zvbi-atsc-cc --atsc -T -9 $FIL.txt -n KCBS

With a simple patch against the today's mercurial tree, as below, this 
works great. For clarity, I renamed channels to channels_list; I'll be 
happy to remove that change if it breaks too many scripts. I don't know 
how to make the change to channel_name so that it's backwardly 
compatible, but maybe we don't need to.


Cheers,
Dave


--- gnutv.c2010-11-27 10:56:57.0 -0800
+++ gnutv-new.c2010-11-27 11:34:41.0 -0800
@@ -54,7 +54,8 @@
 " -frontend frontend to use (default 0)\n"
 " -demux demux to use (default 0)\n"
 " -caslotnum ca slot number to use (default 0)\n"
-" -channels channels.conf file.\n"
+" -channel_list channels.conf file.\n"
+" -channel_name  Name of the channel to tune to.\n"
 " -secfile Optional sec.conf file.\n"
 " -secid ID of the SEC configuration to use, one of:\n"
 " * UNIVERSAL (default) - Europe, 10800 to 11800 
MHz and 11600 to 12700 Mhz,\n"

@@ -82,8 +83,7 @@
 " -timeout Number of seconds to output channel for\n"
 "(0=>exit immediately after successful tuning, 
default is to output forever)\n"

 " -cammenuShow the CAM menu\n"
-" -nomovecaDo not attempt to move CA descriptors from 
stream to programme level\n"

-" \n";
+" -nomovecaDo not attempt to move CA descriptors from 
stream to programme level\n";

 fprintf(stderr, "%s\n", _usage);

 exit(1);
@@ -154,11 +154,16 @@
 if (sscanf(argv[argpos+1], "%i", &caslot_num) != 1)
 usage();
 argpos+=2;
-} else if (!strcmp(argv[argpos], "-channels")) {
+} else if (!strcmp(argv[argpos], "-channel_list")) {
 if ((argc - argpos) < 2)
 usage();
 chanfile = argv[argpos+1];
 argpos+=2;
+} else if (!strcmp(argv[argpos], "-channel_name")) {
+if ((argc - argpos) < 2)
+usage();
+channel_name = argv[argpos+1];
+argpos+=2;
 } else if (!strcmp(argv[argpos], "-secfile")) {
 if ((argc - argpos) < 2)
 usage();
@@ -235,11 +240,6 @@
 } else if (!strcmp(argv[argpos], "-cammenu")) {
 cammenu = 1;
 argpos++;
-} else {
-if ((argc - argpos) != 1)
-usage();
-channel_name = argv[argpos];
-argpos++;
 }
 }


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-dvb] dvbstream fails to tune QAM-256

[David Liontooth]

On 11/24/2010 03:02 AM, Nico Sabbi wrote:

David Liontooth ha scritto:

On 11/19/2010 11:51 PM, David Liontooth wrote:


I'm using Debian's dvbstream 0.6+cvs20090621-1 to capture video and 
closed captioning to file.


If I tune with azap, dvbstream works fine, but I can't get it to 
tune on its own.


In the Debian source code, I activated DVB_ATSC by adding -DDVB_ATSC 
to CFLAGS in the Makefile.


dvbstream -f 64500 -qam 256 -v 49 a 52 -o > test.ts

gives me the error "Unknown FE type".

Suggestions? Is this a problem with an API that has changed since 
dvbstream's last release?


If I change tune.h to allow DVB API >=3 major instead of just ==3, I 
get this (this is a very lightly patched version to allow 8 cards):


# dvbstream -f 621000 -qam 256 -v 8192 -a 8192 -s 6875 -n 10 -o:test.ts
dvbstream v0.7.01 - (C) Dave Chapman 2001-2004
Released under the GPL.
Latest version available from http://dvbtools.sourceforge.net
Open file test.ts
Tuning to 621000 MHz
Using DVB card "Samsung S5H1411 QAM/8VSB Frontend", freq=621000
tuning ATSC to 62100, modulation=5
Getting frontend status
Event:  Frequency: 62100
Modulation: 5
Bit error rate: 0
Signal strength: 0
SNR: 0
UNC: 0
FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER FE_HAS_VITERBI 
FE_HAS_SYNC


MAP 0, file test.ts: From -1 secs, To -1 secs, 0 PIDs -
dvbstream will stop after 10 seconds (0 minutes)
Streaming 1 stream
Caught signal 1 - closing cleanly.

So it tries to tune, and succeeds in a manner of speaking -- if I try 
to tune to an unavailable frequency, it will fail; here we can see it 
locks. However, the Signal strength is zero and the file is empty.


What happened with the ATSC QAM-256 tuning in between DVB API 3.1 and 
now? I'm running 2.6.32.5, with DVB API 5.1.


Cheers,
Dave




it's the usual debian idiocy to package only "official releases".
I refuse to release anything, so unless Dave does it you should use a 
fresh cvs checkout from sourceforge, where the limitation was removed 
years ago.

Hi Nico,

Glad to hear you're around and thanks for responding! The Debian 
maintainer is actually using dvbstream_0.6+cvs20090621, which looks to 
me like the latest version -- I used


cvs -z3 
-d:pserver:anonym...@dvbtools.cvs.sourceforge.net:/cvsroot/dvbtools co 
-P  dvbstream


cvs tune.h still contains the block that restricts the DVB_API to an 
outdated version,


#undef DVB_ATSC
#if defined(DVB_API_VERSION_MINOR)
#if DVB_API_VERSION == 3 && DVB_API_VERSION_MINOR >= 1
#define DVB_ATSC 1
#endif
#endif

and tune.c is not different from the Debian tune.c.

Where is the working code for ATSC QAM tuning? I'd be happy to work with 
you if you can provide some pointers.


Salve,
Dave



--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: zvbi-atsc-cc device node conflict

[David Liontooth]

HoP wrote:

2010/4/17 David Liontooth :
  

HoP wrote:


2010/4/17 Devin Heitmueller :

  

On Fri, Apr 16, 2010 at 7:19 PM, David Liontooth 
wrote:



I'm using a HVR-1850 in digital mode and get good picture and sound
using

 mplayer -autosync 30 -cache 2048 dvb://KCAL-DT

Closed captioning works flawlessly with this command:

zvbi-atsc-cc -C test-cc.txt KCAL-DT

However, if I try to run both at the same time, I get a device node
conflict:

 zvbi-atsc-cc: Cannot open '/dev/dvb/adapter0/frontend0': Device or
resource
busy.

How do I get video and closed captioning at the same time?

  

To my knowledge, you cannot run two userland apps streaming from the
frontend at the same time.  Generally, when people need to do this
sort of thing they write a userland daemon that multiplexes.
Alternatively, you can cat the frontend to disk and then have both
mplayer and your cc parser reading the resulting file.




Usually there is some way, for ex. command line option,
how to say to "second" app that frondend is already locked.
Then second app simply skips tuning at all.

Rest processing is made using demux and dvr devices,
so there is not reason why 2 apps should tune in same
time.

/Honza

  

Thanks! I'm trying to create separate recordings of the video/audio file on
the one hand and the closed captioning on the other.

In one console, I issue

 azap -r KOCE-HD

In a second, I issue

 cat /dev/dvb/adapter0/dvr0 > test-cat3.mpeg

I cannot at the same time run this in a third:

 zvbi-atsc-cc -C test-cc.txt KOCE-HD

because of resource conflict.

Using cat works, but how do I get closed captioning from the resulting mpeg
file?




Very dump way is simply feed zvbi with resulting test-cat3.mpeg.
If this page is correct: http://www.digipedia.pl/man/doc/view/zvbi-atsc-cc.1/
using -t command line option you can get CC by issuing something like
"cat test-cat3.mpeg > zvbi-atsc-cc -ts -C test-cc.txt"

Of course I'm assuming that CC pid is included in recording.
But dunno if azap is demuxing pids others then A/V.

/Honza

  

That's promising but no cigar:

cat test-cat3.mpeg > zvbi-atsc-cc --ts

just feeds the output of the cat into a file called zvbi-atsc-cc (not 
surprisingly).


 cat test-cat3.mpeg | zvbi-atsc-cc --ts

also doesn't work. zvbi-atsc-cc's --ts switch is designed to "Decode a 
DVB Transport Stream on stdin", so if the file created with


 cat /dev/dvb/adapter0/dvr0 > test-cat3.mpeg

qualifies as a DVB Transport Stream, then there's a way to pipe it to 
zvbi-atsc-cc.  How do we get the syntax for this?


I'm also wondering if zvbid, the zvbi daemon, could be used to get a 
text file output from zvbi-atsc-cc. This would seem the more elegant 
solution.


Cheers,
Dave

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: zvbi-atsc-cc device node conflict

[David Liontooth]

HoP wrote:

2010/4/17 Devin Heitmueller :
  

On Fri, Apr 16, 2010 at 7:19 PM, David Liontooth  wrote:


I'm using a HVR-1850 in digital mode and get good picture and sound using

 mplayer -autosync 30 -cache 2048 dvb://KCAL-DT

Closed captioning works flawlessly with this command:

zvbi-atsc-cc -C test-cc.txt KCAL-DT

However, if I try to run both at the same time, I get a device node
conflict:

 zvbi-atsc-cc: Cannot open '/dev/dvb/adapter0/frontend0': Device or resource
busy.

How do I get video and closed captioning at the same time?
  

To my knowledge, you cannot run two userland apps streaming from the
frontend at the same time.  Generally, when people need to do this
sort of thing they write a userland daemon that multiplexes.
Alternatively, you can cat the frontend to disk and then have both
mplayer and your cc parser reading the resulting file.




Usually there is some way, for ex. command line option,
how to say to "second" app that frondend is already locked.
Then second app simply skips tuning at all.

Rest processing is made using demux and dvr devices,
so there is not reason why 2 apps should tune in same
time.

/Honza
  
Thanks! I'm trying to create separate recordings of the video/audio file 
on the one hand and the closed captioning on the other.


In one console, I issue

 azap -r KOCE-HD

In a second, I issue

 cat /dev/dvb/adapter0/dvr0 > test-cat3.mpeg

I cannot at the same time run this in a third:

 zvbi-atsc-cc -C test-cc.txt KOCE-HD

because of resource conflict.

Using cat works, but how do I get closed captioning from the resulting 
mpeg file?


If I can get that to work, that would be great -- but not particularly 
elegant. Does someone have an example of a multiplexing userland daemon 
that allows me to spit out video to one file and text to another?


Cheers,
Dave




--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

zvbi-atsc-cc device node conflict

[David Liontooth]

I'm using a HVR-1850 in digital mode and get good picture and sound using

 mplayer -autosync 30 -cache 2048 dvb://KCAL-DT

Closed captioning works flawlessly with this command:

zvbi-atsc-cc -C test-cc.txt KCAL-DT

However, if I try to run both at the same time, I get a device node 
conflict:


 zvbi-atsc-cc: Cannot open '/dev/dvb/adapter0/frontend0': Device or 
resource busy.


How do I get video and closed captioning at the same time?

Cheers,
Dave

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

PCI slots vanish with hvr-1800

[David Liontooth]

I just purchased some Hauppauge HVR-1800 cards. They work fine in these 
two PCIe slots:


:06:00.0
:09:00.0

These are "PCI Express* Gen1" slots (see details below); the others are 
PCI Express* Gen2.

When I place a card in one of these Gen2 slots, the card does not show up.

What's more, the slot disappears from dmesg. Here's an example.

First, the :04:00.0 slot has no card and shows up like this:

pci :04:00.0: reg 10 64bit mmio: [0xb200-0xb21f]
pci :04:00.0: supports D1 D2
pci :04:00.0: PME# supported from D0 D1 D2 D3hot D3cold
pci :04:00.0: PME# disabled

Second, using a different card, the Hauppauge HVR-1850, we have no problems:

cx23885 :04:00.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
cx23885[0]/0: found at :04:00.0, rev: 4, irq: 19, latency: 0, mmio: 
0xb200

cx23885 :04:00.0: setting latency timer to 64

Third, using the Haupauge HVR-1800, the card does not show up *and*
the four pci lines above about mmio and PME are also gone without a trace.

The problem arises only if an HVR-1800 is in one or more of the slots 4, 
5, and 6.
These slots are not affected if the HVR-1800 cards are in slots 2 and 3 
only.


I get exactly the same behavior on two different machines (same hardware).
The HVR-1800 cards work fine in slots 2 and 3, but fail consistently in 
slots 4, 5, and 6.
The slots themselves are known to be good, since other cards work fine 
in them.


Is this a known problem? PCI Express Gen2 is supposed to be backwardly
compatible with Gen1, but it looks like these PCIe 1.0 cards are knocking
out the PCIe 2.0 resources.

Cheers,
David


Intel Server Board S3420GPLX has six card slots:

– Slot1: One 5-V PCI 32-bit / 33 MHz connector.
– Slot2: One PCI Express* Gen1 x4 (x1 throughput)
connector).
– Slot3: One PCI Express* Gen1 x8 (x4 throughput)
connector).
– Slot4: One PCI Express* Gen2 x8 (x4 throughput)
connector).
– Slot5: One PCI Express* Gen2x8 (x8 throughput)
connector).
– Slot6: One PCI Express* Gen2 x16 (x8 throughput)
connector).


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Audio drop on saa7134

[David Liontooth]

hermann pitton wrote:

Hi,

Am Sonntag, den 20.09.2009, 06:02 -0300 schrieb Mauro Carvalho Chehab:
  

Em Sun, 20 Sep 2009 01:24:12 -0700
David Liontooth  escreveu:



Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 0x00
Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 0xbb
  

This means mute. With this, audio will stop.



Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 0x00
Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 0x10
  

This means unmute.

It seems that the auto-mute code is doing some bad things for you. What happens
if you disable automute? This is a control that you can access via v4l2ctl or
on your userspace application.

Are you using the last version of the driver? I'm not seeing some debug log 
messages
that should be there...



Cheers,
Mauro



despite of still 1001 messages unread, Mauro is right here.

You are also for sure not on a saa7134, likely you would not ever had a
reason to come up here on such. But the much better is to have you now.
  

lspci says

00:07.0 Multimedia controller: Philips Semiconductors SAA7133/SAA7135 
Video Broadcast Decoder (rev 10)


The cards apparently have the saa7133HL-v101 chip. Are you suggesting 
the saa7134 would be better?

Means, you are at least on a saa7133, not able to decode stereo TV sound
on PAL and SECAM systems, vice versa counts for the saa7134 on SYSTEM-M.
  
I'm recording NTSC -- are you saying the saa7133 should be able to 
decode stereo on NTSC?


If "vice versa" for the saa7134, does that mean this chip is not able to 
decode stereo on NTSC?


Sorry, I don't know what SYSTEM-M is in this context.

If you could help me find a chip that avoids this audio drop problem, 
that would be great.

The automute is for convenience of the users, say not to have loud noise
on channel switching. 
I see. That's irrelevant for my purposes; the channels are switched 
before the recording starts.

It is also controlled by different registers for
analog sound and PCI dma sound.
  

I'm using PCI dma sound.

If debugging those issues, one more thing to mention is that external
video in without audio will kick in mute on those cards too at the first
round.

It should be possible to disable all such funny stuff on production
systems, pleasant for the average user's conditions, and then see if
anything should still remain.

On bad mobos, needing PCI quirks and other such stuff, we are likely not
any further than what you have seen on bttv previously, but in 99.9
percent of the known cases it seems to work.

Else Mauro again is right, even audio_debug = 1 should deliver the
related mute ioctl prints.
  
I see -- it may be a couple of weeks before I can run tests on a more 
recent kernel, but I'll do that if turning off audiomute doesn't solve 
the problem.


Cheers,
Dave

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Audio drop on saa7134

[David Liontooth]

Mauro Carvalho Chehab wrote:

Em Sun, 20 Sep 2009 01:24:12 -0700
David Liontooth  escreveu:

  

Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 0x00
Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 0xbb



This means mute. With this, audio will stop.

  

Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 0x00
Sep 18 07:00:01 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 0x10



This means unmute.

It seems that the auto-mute code is doing some bad things for you. What happens
if you disable automute? This is a control that you can access via v4l2ctl or
on your userspace application.
  
Ah, great -- I added "v4lctl -c /dev/video$DEV setattr automute off" to 
the script and verified it works.


Is there a way to turn off the automute on module insertion?

I don't see a lot of difference -- during the initialization, audio is 
still turned off several times, and then left on:


Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 
0x00
Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 
0xbb
Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 
0x00
Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 
0xbb
Sep 21 00:25:19 prato kernel: saa7133[4]/audio: tvaudio thread scan 
start [8]

Sep 21 00:25:19 prato kernel: saa7133[4]/audio: scanning: M
Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x454 = 
0x00
Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x454 = 
0xc0
Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 
0x00
Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x470 = 
0x101010
Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 
0x00
Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 
0xbb
Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 
0x00
Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 
0xbb
Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 
0x00
Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 
0xbb
Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 
0x00
Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 
0xbb
Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 
0x00
Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 
0xbb
Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 
0x00
Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 
0xbb
Sep 21 00:25:19 prato kernel: saa7133[4]/audio: tvaudio thread scan 
start [9]

Sep 21 00:25:19 prato kernel: saa7133[4]/audio: scanning: M
Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x454 = 
0x00
Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x454 = 
0xc0
Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 
0x00
Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x470 = 
0x101010
Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 
0x00
Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 
0x10
Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 
0x00
Sep 21 00:25:19 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 
0x10
Sep 21 00:25:22 prato kernel: saa7133[4]/audio: tvaudio thread status: 
0x13 [M (in progress)]
Sep 21 00:25:22 prato kernel: saa7133[4]/audio: detailed status: 
# init done


And then audio is turned off again at the end of the recording:

Sep 21 00:35:15 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 
0x00
Sep 21 00:35:15 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 
0xbb
Sep 21 00:35:15 prato kernel: saa7133[4]/audio: dsp write reg 0x464 = 
0x00
Sep 21 00:35:15 prato kernel: saa7133[4]/audio: dsp write reg 0x46c = 
0xbb


I'll run with audiomute off for a while and see if it makes a difference 
for the audio drops -- it seems a plausible cause.

Are you using the last version of the driver? I'm not seeing some debug log 
messages
that should be there...
  
I'm still running 2.6.19.1 and 2.6.20.11 on these production machines -- 
if it works, don't fix it.  If there's a clear reason to upgrade, of 
course I'll do that.


It would be a huge relief to discover the audio drops is a driver issue 
that can be fixed with a simple setting.


Cheers,
Dave


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Audio drop on saa7134

[David Liontooth]

Hi Hermann --

I ran in debug mode; results below -- and let me correct a mistake: 
these are 7134 cards, not 7135. I tried some low-profile 7135 cards, but 
got a far higher rate of audio drops and stopped using them.


David Liontooth wrote:

hermann pitton wrote:

Am Montag, den 14.09.2009, 22:16 -0700 schrieb David Liontooth:
 

hermann pitton wrote:
   

Am Montag, den 14.09.2009, 21:02 -0700 schrieb David Liontooth:
   


We've been using saa7135 cards for several years with relatively 
few incidents, but they occasionally drop audio.
I've been unable to find any pattern in the audio drops, so I 
haven't reported it -- I have no way to reproduce the error, but 
it happens regularly, affecting between 3 and 5% of recordings. 
Audio will sometimes drop in the middle of a recording and then 
resume, or else work fine on the next recording.


Hi Dave,

hmm, losing audio on three to five percent of the recordings is a lot!

When we started to talk to each other, we had only saa7134 PAL/SECAM
devices over here.

That has changed a lot, but still no System-M here.

The kernel thread detecting audio on saa7133/35/31e behaves different
from the one on saa7134.

But if you let it run with audio_debug=1, you should have something in
the logs when losing the audio. The kernel audio detection thread must
have been started without success or id find the right thing again. I
would assume caused by a weaker signal in between.

Do you know about the insmod option audio_ddep?

It is pretty hidden and I almost must look it up myself in the code.

Cheers,
Hermann


OK, I'll try running with audio_debug=1. Could you clarify what you 
mean by "The kernel audio detection thread must have been started 
without success or id find the right thing again"? An audio drop can 
be initiated at any point in the recording. A weak signal is a good 
guess, but I've never noticed a correlation with video quality.



You said audio sometimes recovers, than the kernel thread did detect it
again, else failed on the pilots.

 
I didn't know about audio_ddep -- what does it do? I'm not seeing it 
in modinfo.



Oh, are you sure?

  

My mistake -- I'm running 2.6.19 and it's there.
It would be fantastic to get this problem solved -- we've had to 
record everything in parallel to avoid loss, and still very 
occasionally lose sound.



It could also be something else, but that is the point to start.

It stops the kernel audio detection thread and tells him to believe that
only the norm given by insmod should be assumed.

It is some hex in saa7134-audio, don't know it off hand for NTSC.

Wait, i'll look it up. 0x40.
  
Thank you! I'll try turning off the audio detection thread first, and 
then run debug.


options saa7134 card=95,95,95,95 tuner=39,39,39,39 
audio_ddep=0x40,0x40,0x40,0x40 # audio_debug=9,9,9,9


It's a production system so I may need to wait until the weekend.

Cheers,
Dave


I added the audio_ddep value and it appears to have no effect; audio 
drops continued at the previous rate on two machines.


I removed the audio_ddep parameter and added audio_debug=9:

saa7133[4]: found at :02:03.0, rev: 16, irq: 16, latency: 64, mmio: 
0xff2ff800
saa7133[4]: subsystem: 5169:0138, board: LifeView FlyVIDEO3000 
[card=2,insmod option]

saa7133[4]: board init: gpio is 39900
saa7133[4]: there are different flyvideo cards with different tuners
saa7133[4]: out there, you might have to use the tuner= insmod
saa7133[4]: option to override the default value.
tuner 4-0061: chip found @ 0xc2 (saa7133[4])
tuner 4-0061: type set to 39 (LG NTSC (newer TAPC series))
tuner 4-0061: type set to 39 (LG NTSC (newer TAPC series))
tuner 4-0063: chip found @ 0xc6 (saa7133[4])
saa7133[4]: i2c eeprom 00: 69 51 38 01 ff 28 ff ff ff ff ff ff ff ff ff ff
saa7133[4]: i2c eeprom 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[4]: i2c eeprom 20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[4]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[4]: i2c eeprom 40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[4]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[4]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[4]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[4]/audio: dsp write reg 0x464 = 0x00
saa7133[4]/audio: dsp write reg 0x46c = 0xbb
saa7133[4]/audio: dsp write reg 0x464 = 0x00
saa7133[4]/audio: dsp write reg 0x46c = 0xbb
saa7133[4]/audio: dsp write reg 0x474 = 0x00
saa7133[4]/audio: dsp write reg 0x450 = 0x00
saa7133[4]/audio: tvaudio thread scan start [1]
saa7133[4]/audio: scanning: B/G D/K I
saa7133[4]/audio: dsp write reg 0x454 = 0x00
saa7133[4]/audio: dsp write reg 0x454 = 0xac
saa7133[4]/audio: dsp write reg 0x464 = 0x00
saa7133[4]/audio: dsp write reg 0x470 = 0x101010
saa7133[

Re: Reliable work-horse capture device?

[David Liontooth]

Andy Walls wrote:

On Mon, 2009-09-14 at 21:02 -0700, David Liontooth wrote:
  

Mauro Carvalho Chehab wrote:


Hi David,

Em Mon, 14 Sep 2009 19:41:13 -0700
David Liontooth  escreveu:

  
  
We're setting up NTSC cable television capture devices in a handfull of 
remote locations, using four devices to capture around fifty hours a day 
on each location. Capture is scripted and will be ongoing for several 
years. We want to minimize the need for human intervention.


I'm looking for advice on which capture device to use.  My main 
candidates are ivtv (WinTV PVR 500) and USB, but I've not used any of 
the supported USB devices.


Are there USB devices that are sufficiently reliable to hold up under 
continuous capture for years? Are the drivers robust?


I need zvbi-ntsc-cc support, so a big thanks to Michael Krufty for just 
now adding it to em28xx. Do any other USB device chipsets have raw 
closed captioning support?


I would also consider using the PCIe device Hauppauge WinTV-HVR-2200, 
but I need analog support.


Appreciate any advice.



If you look for stability, the most important item is to choose a good stable
server distribution, like RHEL5. You'll be better serviced than using a desktop
distro with some new (not so stable) kernel and tools.

In terms of stability, the PCI devices are generally more reliable, and, among
all drivers, bttv is the winner, since it is the older driver, so, in thesis,
more bugs were solved on it. That's the reason why several surveillance systems
are still today based on bttv. If you need a newer hardware, then you may choose
saa7134, cx88 or ivtv devices.

I don't recommend using an USB hardware for such hard usage: it will probably
have a shorter life (since it is not as ventilated as a PCI device on a
server cabinet), and you might experience troubles after long plays. In terms
of USB with analog support, em28xx driver is the more stable, and we recently
fixed some bugs on it, related to memory consumption along the time (it used to
forget to free memory, resulting on crashes, after several stream
start/stop's). 


There's a tool at v4l2-apps/test made to stress a video driver, made by
Douglas. I suggest that you should run it with the board you'll choose to be
sure that you won't have memory garbage along driver usage.

Cheers,
Mauro
  
  

Thank you, Mauro! I much appreciate the advice.

I also see I misattributed the zvbi-ntsc-cc support for em28xx -- kudos 
goes to Devin Heitmueller for great work on this.


As for the ventilation issue for USB devices, that may not be a serious 
obstacle. If the USB sticks such as Hauppauge HVR-950 have reliable 
components, we could strip the plastic casing and mount the unit next to 
a fan inside the case.


Memory leaks would be a serious problem on the other hand; thank you for 
pointing to the stress test.


I would be happy to use bttv, but I can't find cards. I also need to 
grab audio off the PCI bus, which only some bttv cards support.


We've been using saa7135 cards for several years with relatively few 
incidents, but they occasionally drop audio.
I've been unable to find any pattern in the audio drops, so I haven't 
reported it -- I have no way to reproduce the error, but it happens 
regularly, affecting between 3 and 5% of recordings. Audio will 
sometimes drop in the middle of a recording and then resume, or else 
work fine on the next recording.


Our fallback is ivtv. I was hoping to use USB so that we could get 
blades instead of 3U cases; it's also getting hard to find good 
motherboards with four PCI slots.




I will point out that, for a fallback position, the cx18 driver also
performs very reliably with essentially the same feature set as ivtv
(since it started out as a cut and paste from ivtv).

The HVR-1600 is the card with which I do most of my testing.  It is a
PCI bus device and can perform analog (with VBI) and digital capture
simultaneously, but not 2 analog streams simultaneously.  I know of two
users who have at least 3 of these boards in one machine.  (I mention
the HVR-1600, in case you have a hard time finding the PVR-500 or
similar analog only cards.)

Of course for you, it sounds like one analog capture device per PCI slot
is suboptimal.  From a bus throughput perspective, I'd assume you'd
really want a multiple analog input PCI or PCIe capture card, that could
do compression on board.

Regards,
Andy
  

Thanks Andy, that's a useful suggestion for a fallback.

Cheers,
Dave

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Audio drop on saa7134

[David Liontooth]

hermann pitton wrote:

Am Montag, den 14.09.2009, 22:16 -0700 schrieb David Liontooth:
  

hermann pitton wrote:


Am Montag, den 14.09.2009, 21:02 -0700 schrieb David Liontooth:
  
  


We've been using saa7135 cards for several years with relatively few 
incidents, but they occasionally drop audio.
I've been unable to find any pattern in the audio drops, so I haven't 
reported it -- I have no way to reproduce the error, but it happens 
regularly, affecting between 3 and 5% of recordings. Audio will 
sometimes drop in the middle of a recording and then resume, or else 
work fine on the next recording.



Hi Dave,

hmm, losing audio on three to five percent of the recordings is a lot!

When we started to talk to each other, we had only saa7134 PAL/SECAM
devices over here.

That has changed a lot, but still no System-M here.

The kernel thread detecting audio on saa7133/35/31e behaves different
from the one on saa7134.

But if you let it run with audio_debug=1, you should have something in
the logs when losing the audio. The kernel audio detection thread must
have been started without success or id find the right thing again. I
would assume caused by a weaker signal in between.

Do you know about the insmod option audio_ddep?

It is pretty hidden and I almost must look it up myself in the code.

Cheers,
Hermann

  
  
OK, I'll try running with audio_debug=1. Could you clarify what you mean 
by "The kernel audio detection thread must have been started without 
success or id find the right thing again"? An audio drop can be 
initiated at any point in the recording. A weak signal is a good guess, 
but I've never noticed a correlation with video quality.



You said audio sometimes recovers, than the kernel thread did detect it
again, else failed on the pilots.

  
I didn't know about audio_ddep -- what does it do? I'm not seeing it in 
modinfo.



Oh, are you sure?

  

My mistake -- I'm running 2.6.19 and it's there.
It would be fantastic to get this problem solved -- we've had to record 
everything in parallel to avoid loss, and still very occasionally lose 
sound.



It could also be something else, but that is the point to start.

It stops the kernel audio detection thread and tells him to believe that
only the norm given by insmod should be assumed.

It is some hex in saa7134-audio, don't know it off hand for NTSC.

Wait, i'll look it up. 0x40.
  
Thank you! I'll try turning off the audio detection thread first, and 
then run debug.


options saa7134 card=95,95,95,95 tuner=39,39,39,39 
audio_ddep=0x40,0x40,0x40,0x40 # audio_debug=9,9,9,9


It's a production system so I may need to wait until the weekend.

Cheers,
Dave

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Audio drop on saa7134

[David Liontooth]

hermann pitton wrote:

Am Montag, den 14.09.2009, 21:02 -0700 schrieb David Liontooth:
  


We've been using saa7135 cards for several years with relatively few 
incidents, but they occasionally drop audio.
I've been unable to find any pattern in the audio drops, so I haven't 
reported it -- I have no way to reproduce the error, but it happens 
regularly, affecting between 3 and 5% of recordings. Audio will 
sometimes drop in the middle of a recording and then resume, or else 
work fine on the next recording.



Hi Dave,

hmm, losing audio on three to five percent of the recordings is a lot!

When we started to talk to each other, we had only saa7134 PAL/SECAM
devices over here.

That has changed a lot, but still no System-M here.

The kernel thread detecting audio on saa7133/35/31e behaves different
from the one on saa7134.

But if you let it run with audio_debug=1, you should have something in
the logs when losing the audio. The kernel audio detection thread must
have been started without success or id find the right thing again. I
would assume caused by a weaker signal in between.

Do you know about the insmod option audio_ddep?

It is pretty hidden and I almost must look it up myself in the code.

Cheers,
Hermann

  
OK, I'll try running with audio_debug=1. Could you clarify what you mean 
by "The kernel audio detection thread must have been started without 
success or id find the right thing again"? An audio drop can be 
initiated at any point in the recording. A weak signal is a good guess, 
but I've never noticed a correlation with video quality.


I didn't know about audio_ddep -- what does it do? I'm not seeing it in 
modinfo.


It would be fantastic to get this problem solved -- we've had to record 
everything in parallel to avoid loss, and still very occasionally lose 
sound.


Cheers,
Dave



--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Reliable work-horse capture device?

[David Liontooth]

Mauro Carvalho Chehab wrote:

Em Mon, 14 Sep 2009 21:02:52 -0700
David Liontooth  escreveu:

  
As for the ventilation issue for USB devices, that may not be a serious 
obstacle. If the USB sticks such as Hauppauge HVR-950 have reliable 
components, we could strip the plastic casing and mount the unit next to 
a fan inside the case.



Yes, this may work.

Don't forget that, if you use USB devices, you'll probably need one separate USB
buses per each device, due to USB limits in terms of the maximum number of isoc
packets per second. If you don't require high quality, you could try to use
a format that requires less than 16 bits per pixel or 320x240 pixels, in order
to have more than one device per bus.
  

Thanks for pointing this out.
  
I would be happy to use bttv, but I can't find cards. I also need to 
grab audio off the PCI bus, which only some bttv cards support.


We've been using saa7135 cards for several years with relatively few 
incidents, but they occasionally drop audio.
I've been unable to find any pattern in the audio drops, so I haven't 
reported it -- I have no way to reproduce the error, but it happens 
regularly, affecting between 3 and 5% of recordings. Audio will 
sometimes drop in the middle of a recording and then resume, or else 
work fine on the next recording.



saa7134 has a thread to detect audio audio stereo mode. Maybe there is a bug
somewhere there.
  

Interesting idea -- anything I can do to debug?
  
Our fallback is ivtv. I was hoping to use USB so that we could get 
blades instead of 3U cases; it's also getting hard to find good 
motherboards with four PCI slots.



The current best relation in terms of slots is the new cx25821. It has 8
simultaneous inputs at 60 fps per each PCIe board. If you don't need a tuner,
this design could be very interesting. The driver was written by Conexant, and
it is not yet present on any distribution (I just committed it today - at
staging - since it needs some cleanups to match kernel CodingStyle).
  
Wow, that's great to get support for this powerful device. We do need 
tuners, though -- we're capturing straight from RF television cable. 
Otherwise a beautiful product, even with h264 compression, which is what 
we need.


Cheers,
Dave


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Reliable work-horse capture device?

[David Liontooth]

Mauro Carvalho Chehab wrote:

Hi David,

Em Mon, 14 Sep 2009 19:41:13 -0700
David Liontooth  escreveu:

  
We're setting up NTSC cable television capture devices in a handfull of 
remote locations, using four devices to capture around fifty hours a day 
on each location. Capture is scripted and will be ongoing for several 
years. We want to minimize the need for human intervention.


I'm looking for advice on which capture device to use.  My main 
candidates are ivtv (WinTV PVR 500) and USB, but I've not used any of 
the supported USB devices.


Are there USB devices that are sufficiently reliable to hold up under 
continuous capture for years? Are the drivers robust?


I need zvbi-ntsc-cc support, so a big thanks to Michael Krufty for just 
now adding it to em28xx. Do any other USB device chipsets have raw 
closed captioning support?


I would also consider using the PCIe device Hauppauge WinTV-HVR-2200, 
but I need analog support.


Appreciate any advice.



If you look for stability, the most important item is to choose a good stable
server distribution, like RHEL5. You'll be better serviced than using a desktop
distro with some new (not so stable) kernel and tools.

In terms of stability, the PCI devices are generally more reliable, and, among
all drivers, bttv is the winner, since it is the older driver, so, in thesis,
more bugs were solved on it. That's the reason why several surveillance systems
are still today based on bttv. If you need a newer hardware, then you may choose
saa7134, cx88 or ivtv devices.

I don't recommend using an USB hardware for such hard usage: it will probably
have a shorter life (since it is not as ventilated as a PCI device on a
server cabinet), and you might experience troubles after long plays. In terms
of USB with analog support, em28xx driver is the more stable, and we recently
fixed some bugs on it, related to memory consumption along the time (it used to
forget to free memory, resulting on crashes, after several stream
start/stop's). 


There's a tool at v4l2-apps/test made to stress a video driver, made by
Douglas. I suggest that you should run it with the board you'll choose to be
sure that you won't have memory garbage along driver usage.

Cheers,
Mauro
  

Thank you, Mauro! I much appreciate the advice.

I also see I misattributed the zvbi-ntsc-cc support for em28xx -- kudos 
goes to Devin Heitmueller for great work on this.


As for the ventilation issue for USB devices, that may not be a serious 
obstacle. If the USB sticks such as Hauppauge HVR-950 have reliable 
components, we could strip the plastic casing and mount the unit next to 
a fan inside the case.


Memory leaks would be a serious problem on the other hand; thank you for 
pointing to the stress test.


I would be happy to use bttv, but I can't find cards. I also need to 
grab audio off the PCI bus, which only some bttv cards support.


We've been using saa7135 cards for several years with relatively few 
incidents, but they occasionally drop audio.
I've been unable to find any pattern in the audio drops, so I haven't 
reported it -- I have no way to reproduce the error, but it happens 
regularly, affecting between 3 and 5% of recordings. Audio will 
sometimes drop in the middle of a recording and then resume, or else 
work fine on the next recording.


Our fallback is ivtv. I was hoping to use USB so that we could get 
blades instead of 3U cases; it's also getting hard to find good 
motherboards with four PCI slots.


Cheers,
Dave








--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reliable work-horse capture device?

[David Liontooth]

We're setting up NTSC cable television capture devices in a handfull of 
remote locations, using four devices to capture around fifty hours a day 
on each location. Capture is scripted and will be ongoing for several 
years. We want to minimize the need for human intervention.


I'm looking for advice on which capture device to use.  My main 
candidates are ivtv (WinTV PVR 500) and USB, but I've not used any of 
the supported USB devices.


Are there USB devices that are sufficiently reliable to hold up under 
continuous capture for years? Are the drivers robust?


I need zvbi-ntsc-cc support, so a big thanks to Michael Krufty for just 
now adding it to em28xx. Do any other USB device chipsets have raw 
closed captioning support?


I would also consider using the PCIe device Hauppauge WinTV-HVR-2200, 
but I need analog support.


Appreciate any advice.

Dave


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html