-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Iyán,
The scheduling for GetUSBCamera is a bit different. The docs (PROCESSORS.md) say it "outputs one frame per flow file" --it should probably say "one flow file per frame." The reason this processor is a bit different is that the underlying camera library (libuvc) registers a callback that we provide, which is called back at the given FPS. In this callback, we generate and transfer a new flow file. This is done so that the flow file outputs are synchronized with the frame rate of the camera. This reduces latency and allows us to avoid needing a temporary buffer for onTrigger to copy from. The downside is that the configurating is different (scheduling is affected only by FPS, nothing else). The onTrigger function of GetUSBCamera does nothing, so the usual scheduling mechanisms will do nothing. As for the image dimensions/quality, GetUSBCamera will enumerate all supported modes for the camera and select the highest dimensions/quality for the given FPS. The dimensions are dictated by the camera hardware/drivers, and not us. In order to change the dimensions after collecting frame data, an additional expensive resize operation would need to be performed, so it may be better to have that explicitly done in a follow-on processor. This is something we could look at changing in GetUSBCamera, but we should carefully consider the efficiency and configuration UX. A possibility might be to let the user specify a preferred format in the config, and select the closest supported by the hardware/drivers. We could also look at supporting resize in the processor, but that has some downsides (mainly efficiency). If you are using the images as inputs to a TensorFlow graph, a good place to resize may be at the start of the TensorFlow graph itself. That way the resize operation can be parallelized and possibly hardware accelerated. I have added a ticket [1] to clarify this in the documentation. Regards, Andy I.C. [1] https://issues.apache.org/jira/browse/MINIFICPP-464 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJa3fU6AAoJEG1+mBKNMpID16cIAK7Tk3ykSzCE/9TLb2dLvOyf jWd0Ced/KhjKBBA+eN6iHxe4eYs/gQtP+Rix+kP93gLTPrZ7vF4Cxb3jT3zra6pI DaCxp6zUzcGtd960XXnQ1wEii1rIyamokuK8A4uIUFKgcZK6WKgRlcGr6lOWQ5c3 J6/VJNb/eL076lDq6Xj4zU0msxsTMUZWBXJjZ5K6JlI+Y983u+bfNKqnUArWgt/z KIp8DIBXnib7xNQAIrk8k7THZkS+0/SENSt9j8OV/P2rkXUaWmBwFSX1F4s+k9Dq 4iUvga9mSwvuThR7IiJqrcDJjwo09qHWOVAoTPkzcjYlIGGshUOeIoHcmWKJV24= =3esw -----END PGP SIGNATURE----- Sent from ProtonMail, Swiss-based encrypted email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On April 23, 2018 10:35 AM, Mendez Veiga, Iyan <[email protected]> wrote: > > > Ok, thanks Marc. I have tried your file (just making it simpler and adding a > RPG) and timer does not work for me... I will send the log later when I > arrive home. > > So, just a silly question. Imagine I want a picture every 10 seconds. I would > just have to change scheduling period to 10 sec or 10000 msec, right?. Does > this work even if I specify FPS: 24? > > I noticed that the video profile is chosen based on the FPS value. If I set > FPS: 1 I get very large images while with FPS: 24 I get smaller 800x600 > images. I guess this will be configured as a property in the future. > > Best regards, > > Iyán > > -----Mensaje original----- > > De: Marc P. [mailto:[email protected]] > > Enviado el: lunes, 23 de abril de 2018 13:16 > > Para: [email protected] > > Asunto: Re: [NIFI-CPP] Issues with TIMER_DRIVEN and CRON_DRIVEN > > This Message originated from a Non-ArcelorMittal source > > Iyán, > > Yes, both strategies seem to work. > > Here is my config file > > https://urldefense.proofpoint.com/v2/url?u=https-3A__gist.github.com_phrocker_a209b5163044a5bb3c2e6ac4662ce143&d=DwIFaQ&c=y5LGzd1hT50ruE_IlUH7x8VGgWz9W0tFVWT6rSvPUKA&r=OqJOXvZGIFafgLt7Uocjlzsiwprj2_HJJ0p7HG9IsupasVjguMhbhoUfzdA5V_Qn&m=CCOIqqrapqve7SfBS7uoDgFCrVh83PSU7mN-ZblHnho&s=ehLOY9yBJ2LpM0Jnl-xWpiL5r35oVQnvoglF9U_m118&e= > > Below is the output form my pi. Due to the time it takes to create a PNG and > the scheduling strategy it usually ends up being about a second between > pictures. When I reduce my configuration to what you have ( for the timing > config options ) I maintain the same pattern of taking a picture every 900 > ms. Logs may help further diagnose the issue. > > [2018-04-23 11:11:17.484] > > [org::apache::nifi::minifi::processors::GetUSBCamera] [debug] Got frame > > [2018-04-23 11:11:18.690] > > [org::apache::nifi::minifi::processors::GetUSBCamera] [debug] Got frame > > [2018-04-23 11:11:19.850] > > [org::apache::nifi::minifi::processors::GetUSBCamera] [debug] Got frame > > [2018-04-23 11:11:20.998] > > [org::apache::nifi::minifi::processors::GetUSBCamera] [debug] Got frame > > [2018-04-23 11:11:22.145] > > [org::apache::nifi::minifi::processors::GetUSBCamera] [debug] Got frame > > [2018-04-23 11:11:23.284] > > [org::apache::nifi::minifi::processors::GetUSBCamera] [debug] Got frame > > [2018-04-23 11:11:24.427] > > [org::apache::nifi::minifi::processors::GetUSBCamera] [debug] Got frame > > [2018-04-23 11:11:25.573] > > [org::apache::nifi::minifi::processors::GetUSBCamera] [debug] Got frame > > [2018-04-23 11:11:26.718] > > [org::apache::nifi::minifi::processors::GetUSBCamera] [debug] Got frame > > [2018-04-23 11:11:27.860] > > [org::apache::nifi::minifi::processors::GetUSBCamera] [debug] Got frame > > [2018-04-23 11:11:28.998] > > [org::apache::nifi::minifi::processors::GetUSBCamera] [debug] Got frame > > [2018-04-23 11:11:30.143] > > [org::apache::nifi::minifi::processors::GetUSBCamera] [debug] Got frame > > [2018-04-23 11:11:31.286] > > [org::apache::nifi::minifi::processors::GetUSBCamera] [debug] Got frame > > [2018-04-23 11:11:32.429] > > [org::apache::nifi::minifi::processors::GetUSBCamera] [debug] Got frame > > [2018-04-23 11:11:33.573] > > [org::apache::nifi::minifi::processors::GetUSBCamera] [debug] Got frame > > [2018-04-23 11:11:34.717] > > [org::apache::nifi::minifi::processors::GetUSBCamera] [debug] Got frame > > [2018-04-23 11:11:35.875] > > [org::apache::nifi::minifi::processors::GetUSBCamera] [debug] Got frame > > [2018-04-23 11:11:36.999] > > [org::apache::nifi::minifi::processors::GetUSBCamera] [debug] Got frame > > [2018-04-23 11:11:38.129] > > [org::apache::nifi::minifi::processors::GetUSBCamera] [debug] Got frame > > [2018-04-23 11:11:39.255] > > [org::apache::nifi::minifi::processors::GetUSBCamera] [debug] Got frame > > [2018-04-23 11:11:40.384] > > [org::apache::nifi::minifi::processors::GetUSBCamera] [debug] Got frame > > [2018-04-23 11:11:41.513] > > [org::apache::nifi::minifi::processors::GetUSBCamera] [debug] Got frame > > [2018-04-23 11:11:42.639] > > [org::apache::nifi::minifi::processors::GetUSBCamera] [debug] Got frame > > On Mon, Apr 23, 2018 at 6:27 AM, Mendez Veiga, Iyan > [email protected] wrote: > > > Ok, thanks Marc! > > > > And do they work for you both TIMER_DRIVEN and EVENT_DRIVEN in the > > > > raspberry? Can you send me a config.yml you have using the GetUSBCamera? > > > > Best regards, > > > > Iyán > > > > De: Marc [mailto:[email protected]] > > > > Enviado el: lunes, 23 de abril de 2018 0:22 > > > > Para: [email protected] > > > > Asunto: Re: [NIFI-CPP] Issues with TIMER_DRIVEN and CRON_DRIVEN > > > > This Message originated from a Non-ArcelorMittal source > > > > I wanted to follow up and say that timer driven and event driven are > > > > the only scheduling strategies available in minifi c++. Cron is not a > > > > supported strategy yet. Sorry for not mentioning this earlier > > > > On Sun, Apr 22, 2018, 4:05 PM Iyán Méndez Veiga [email protected] wrote: > > > > Hi, > > > > I haven't been able to configure MiNiFi to take pictures every 30 > > > > seconds using GetUSBCamera processor. I have the following in the > > > > config.yml > > > > - name: take_picture > > > > class: GetUSBCamera > > > > max concurrent tasks: 1 > > > > scheduling strategy: TIMER_DRIVEN > > > > scheduling period: 30 sec > > > > auto-terminated relationships list: > > > > - failure > > > > Properties: > > > > FPS: 1 > > > > Format: PNG > > > > USB Vendor ID: 0x046d > > > > USB Product ID: 0x082d > > > > > > The processor ignores the scheduling period and it takes pictures > > > > continuously. I tried to use the CRON_DRIVEN but any processor seems > > > > to work. > > > > Perhaps is that I didn't understand how to use it reading this: > > > > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.quartz-2Dsched > > > > uler.org_documentation_quartz-2D2.x_tutorials_&d=DwIFaQ&c=y5LGzd1hT50r > > > > uE_IlUH7x8VGgWz9W0tFVWT6rSvPUKA&r=OqJOXvZGIFafgLt7Uocjlzsiwprj2_HJJ0p7 > > > > HG9IsupasVjguMhbhoUfzdA5V_Qn&m=CCOIqqrapqve7SfBS7uoDgFCrVh83PSU7mN-Zbl > > > > Hnho&s=cq8_LXeshv-OxOvRYMhj4Dh5LZF-mi3SB5QQLeBHOH4&e= > > > > crontrigger.html > > > > - name: take_picture > > > > class: GetUSBCamera > > > > max concurrent tasks: 1 > > > > scheduling strategy: CRON_DRIVEN > > > > scheduling period: 0/30 * * * * * > > > > auto-terminated relationships list: > > > > - failure > > > > Properties: > > > > FPS: 1 > > > > Format: PNG > > > > USB Vendor ID: 0x046d > > > > USB Product ID: 0x082d > > > > > > Hope anyone can help me. By the way, is there any place to check > > > > current open/ known issues and bugs? > > > > Thanks, > > > > Iyán > > > > -- > > > > Iyán Méndez Veiga | Physicist > > > > GPG: 0x422E3694311E5AC1 > > > > Web: > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__iyanmv.com&d=DwIF > > > > aQ&c=y5LGzd1hT50ruE_IlUH7x8VGgWz9W0tFVWT6rSvPUKA&r=OqJOXvZGIFafgLt7Uoc > > > > jlzsiwprj2_HJJ0p7HG9IsupasVjguMhbhoUfzdA5V_Qn&m=CCOIqqrapqve7SfBS7uoDg > > > > FCrVh83PSU7mN-ZblHnho&s=l40luoV3hDW2kW14VMDqZpr-Jy6vh_JSVkpF4uVg_Ns&e= > > > > ♫♪.ılılıll|̲̅̅●̲̅̅|̲̅̅=̲̅̅|̲̅̅●̲̅̅|llılılı.♫♪
