opensuse
[Arriba] [Todas las Listas]

Re: [opensuse] howto Conseguir detalles de 1394 (firewire) creación de

To: suse <opensuse@xxxxxxxxxxxx>
Subject: Re: [opensuse] howto Conseguir detalles de 1394 (firewire) creación de dispositivo en tapón de cámara-en (necesidad BASH prueba)
From: "David C. Rankin" <drankinatty@xxxxxxxxxxxxxxxxxx>
Date: Mon, 26 Sep 2011 11:01:57 -0500
Delivered-to: opensuse@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 26 Sep 2011 12:02:45 -0400
Envelope-to: traductor@xxxxxxxxxxx
In-reply-to: <1317018879.7429.12.camel@acme.pacific>
List-archive: <http://lists.opensuse.org/opensuse/>
List-help: <mailto:opensuse+help@opensuse.org>
List-owner: <mailto:opensuse+owner@opensuse.org>
List-post: <mailto:opensuse@opensuse.org>
List-subscribe: <mailto:opensuse+subscribe@opensuse.org>
List-unsubscribe: <mailto:opensuse+unsubscribe@opensuse.org>
Mailing-list: contact opensuse+help@xxxxxxxxxxxx; run by mlmmj
Organization: Rankin Law Firm, PLLC
References: <4E7E9D8B.9070306@suddenlinkmail.com> <4E7EA1AD.8050609@gmail.com> <4E7F74B1.6060402@suddenlinkmail.com> <1317018879.7429.12.camel@acme.pacific>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110907 Thunderbird/6.0.2
En 09/26/2011 01:34 AM, Roger *Oberholtzer escribió:
En Sol, 2011-09-25 en 13:36 -0500, David *C. *Rankin Escribió:


utilizo *firewire cámaras, no vídeo. Ellos tapón en justo bien. No tienen cualquier local *storage, así que el acceso es realmente justo *grabbing una imagen nueva. Tengo un *udev regla que asegura permisos propios. Pienso que esto es
diferente para cámaras de vídeo. Pero la idea general puede ser igual:

*KERNEL=="crudo1394*", NOMBRE="%*k", vídeo="de GRUPO", MODO="666", OPCIONES="última_regla"
*KERNEL=="*dv1394*", NOMBRE="%*k", *SYMLINK+="*dv1394/%*n", vídeo="de GRUPO", MODO="666", OPCIONES="última_regla"
*KERNEL=="vídeo1394*", NOMBRE="%*k", *SYMLINK+="vídeo1394/%*n", vídeo="de GRUPO", MODO="666", OPCIONES="última_regla"

La cosa única he encontrado es que si los cámaras son *unplugged/*plugged
demasiado deprisa, los 1349 conductores a veces *complain sobre qué dispositivos es
un maestro. (O algunos tal texto similar - él nunca bastante pasado para
acontecer un asunto que recuerdo en detalle.)

 *dvgrab Lista todo el interesante *info sobre los cámaras encontrados cuándo
empieza? Si tan, quizás que muestra una diferencia.


Roger,

*Thanks. *dvgrab No Te da una parcela entera de información cuándo empieza otro que diciéndote lo:

AV Encontrado/*C dispositivo con *GUID 0*x08004601017*ede99

Lo te da que información a toda costa. (Cuando mucho tiempo cuando puede encontrar un dispositivo). Si hay ningún cámara lo encontró justo salidas con el "Ningún Cámara mensaje" Encontrado.

En mi caso, el cámara es siempre encontrado y *dvgrab SIEMPRE lo puede controlar (*rewind, juego, *etc..) El problema estoy tratando es cuándo empieza 'juego' para empezar la captura - a veces hay ninguna captura, nada grabado a disco, incluso aunque *dvgrab ha empezado el 'juego' modo en el cámara justo bien.

La indicación consigo encima si hay un exitoso descargar empezado es que *dvgrab emite la Captura "el mensaje" Empezado cuándo descarga empieza. Para el tiempo cuándo el cámara es puesto en modo de juego y nada es descargado, *dvgrab justo sienta allí con el "Esperando para *DV..." Mensaje (incluso aunque *dvgrab ha *rewound la cinta y empezado el cámara que juega). En cualquier caso, *dvgrab jugará aunque la cinta entera antes de salir... (Aproximadamente una hora +- 5 minutos)

estoy utilizando el siguiendo línea de orden para empezar *dvgrab. Justo repito la fecha así que tengo una referencia puesto que cuándo empecé el descargar tan sé para comprobar atrás en una hora para cambiar cintas y empezarlo otra vez. (La primera "Captura el mensaje" Empezado es mina del *CLI [elección pobre de palabras]) La segunda "Captura el mensaje" Empezado es el emitido por *dvgrab. Corro *dvgrab en un *subshell de modo que cualesquier mensajes de error del *dvgrab *stderr la corriente es *logged en el orden correcto y no consigue *intertwined con cualesquier mensajes del *tee *stderr corriente (no que he nunca tuvo ninguno de *tee). El descargar/ningún descargar el asunto ocurre a toda costa de si te corrido *dvgrab en un *subshell.

10:37 *archangel:/*dat_*e/*dv/nuevo> (eco -*e "\*nCapture Empezó: $(fecha '+%*b %*e %*T')\*n"; *dvgrab -*rewind -*timestamp -*autosplit=3600 -el formato crudo *dcrv- 2>&1) | *tee -un /*dat_*e/*dv/captura.*log

La Captura Empezó: *Sep 26 10:37:52

AV Encontrado/*C dispositivo con *GUID 0*x08004601017*ede99
Esperando para *DV...
La Captura Empezó   <== esto es el *dvgrab mensaje
"*dcrv-1999.12.24_17-11-33.*dv": 999.98 *MiB 8738 marcos *timecode 00:04:51.18 fecha 1999.12.24 17:24:26 "*dcrv-1999.12.24_17-24-26.*dv": 656.78 *MiB 5739 marcos *timecode 00:08:03.05 fecha 1999.12.24 18:14:28
<*snip>

En cosa podría hacer es para esperar para 3-4 minutos después de empezar *dvgrab y entonces control para "la Captura mensaje" Empezado -- pero francamente, soy *unclear cómo haría aquello de dentro de un guión desde procesar en el guión está esperando para *dvgrab para acabar?? Cualesquier ideas en cómo para hacer esto sería *welcomed. No sé, quizás empezar un temporizador en el guión antes del *dvgrab llamada que espera 5 minutos, controles para "la Captura Empezada" y si no encontrado, mata el *dvgrab PID y emite un error?? Tendré que cavar más a *BASH para imaginar que uno fuera. *dnh, *bkw -- tú escuchando :)

--
David *C. *Rankin, *J.*D.,*P.*E.
--
A *unsubscribe, *e-correo: *opensuse+unsubscribe@xxxxxxxxxxxx
Puesto que órdenes adicionales, *e-correo: *opensuse+help@xxxxxxxxxxxx


On 09/26/2011 01:34 AM, Roger Oberholtzer wrote:
On Sun, 2011-09-25 at 13:36 -0500, David C. Rankin wrote:


I use firewire cameras, not video. They plug in just fine. They do not
have any local storage, so access is really just grabbing a new image. I
have a udev rule that ensures proper permissions. I think this is
different for video cameras. But the general idea may be the same:

KERNEL=="raw1394*", NAME="%k", GROUP="video", MODE="666", OPTIONS="last_rule"
KERNEL=="dv1394*", NAME="%k", SYMLINK+="dv1394/%n", GROUP="video", MODE="666", OPTIONS="last_rule"
KERNEL=="video1394*", NAME="%k", SYMLINK+="video1394/%n", GROUP="video", MODE="666", OPTIONS="last_rule"

The only thing I have found is that if the cameras are unplugged/plugged
too quickly, the 1349 drivers sometimes complain about which devices is
a master. (Or some such similar text - it never happened enough to
become an issue that I remember in detail.)

Does dvgrab list all the interesting info about the found cameras when
it starts? If so, perhaps that shows a difference.


Roger,

Thanks. dvgrab doesn't give you a whole lot of information when it starts other than telling you it:

Found AV/C device with GUID 0x08004601017ede99

It gives you that information regardless. (as long as it can find a device). If there is no camera found it just exits with the "No Camera Found" message.

In my case, the camera is always found and dvgrab can ALWAYS control it (rewind, play, etc..) The problem I'm dealing with is when it starts 'play' to begin the capture - sometimes there is no capture, nothing recorded to disk, even though dvgrab has started the 'play' mode on the camera just fine.

The indication I get on whether there is a successful download started is that dvgrab issues the "Capture Started" message when download begins. For the times when the camera is put in play mode and nothing is downloaded, dvgrab just sits there with the "Waiting for DV..." message (even though dvgrab has rewound the tape and started the camera playing). In either case, dvgrab will play though the entire tape before exiting... (roughly an hour +- 5 minutes)

I am using the following command line to start dvgrab. I just echo the date so I have a reference for when I started the download so I know to check back in an hour to switch tapes and start it again. (the first "Capture Started" message is mine from the CLI [poor choice of words]) The second "Capture Started" message is the one issued by dvgrab. I run dvgrab in a subshell so that any error messages from the dvgrab stderr stream are logged in the correct order and don't get intertwined with any messages from the tee stderr stream (not that I've ever had any from tee). The download/no download issue occurs regardless of whether you run dvgrab in a subshell.

10:37 archangel:/dat_e/dv/new> (echo -e "\nCapture Started: $(date '+%b %e %T')\n"; dvgrab -rewind -timestamp -autosplit=3600 -format raw dcrv- 2>&1) | tee -a /dat_e/dv/capture.log

Capture Started: Sep 26 10:37:52

Found AV/C device with GUID 0x08004601017ede99
Waiting for DV...
Capture Started   <== this is the dvgrab message
"dcrv-1999.12.24_17-11-33.dv": 999.98 MiB 8738 frames timecode 00:04:51.18 date 1999.12.24 17:24:26 "dcrv-1999.12.24_17-24-26.dv": 656.78 MiB 5739 frames timecode 00:08:03.05 date 1999.12.24 18:14:28
<snip>

On thing I could do is to wait for 3-4 minutes after starting dvgrab and then check for the "Capture Started" message -- but frankly, I'm unclear how I would do that from within a script since processing in the script is waiting for dvgrab to finish?? Any ideas on how to do this would be welcomed. I don't know, maybe start a timer in the script before the dvgrab call that waits 5 minutes, checks for the "Capture Started" and if not found, kills the dvgrab PID and issues an error?? I'll have to dig more into BASH to figure that one out. dnh, bkw -- you listening :)

--
David C. Rankin, J.D.,P.E.
--
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse+help@xxxxxxxxxxxx


<Anterior por Tema] Tema Actual [Siguiente por Tema>