**** BEGIN LOGGING AT Wed Apr 03 02:59:57 2019 **** BEGIN LOGGING AT Wed Apr 03 14:09:24 2019 Apr 03 19:28:03 https://www.linuxjournal.com/content/25-years-later-interview-linus-torvalds Fully agree re social media Apr 03 21:07:04 1:02 < DocScrutinizer05> alias n900cam='gst-launch-1.0 udpsrc port=10010 caps=application/x-rtp,clock-rate=90000 ! rtpjitterbuffer ! etc .... what does it do? i'm curious, but don't have a pc at hand to test Apr 03 21:17:52 sicelo: it starts a video source on N900 from main camera to WLAN, RTP jpeg format/protocol. And same time it starts a viewer on the interactive side (here: my PC) Apr 03 21:18:52 prerequisite: nothing blocking UDP data on destination port 10010 Apr 03 21:20:00 sicelo: I just fire a `n900cam` in a shell of my PC Apr 03 21:20:31 (could use a desktop icon or a startmenu entry as well) Apr 03 21:22:48 how is the latency? does the n900 cope? Apr 03 21:42:53 latency ~0.5s Apr 03 21:44:16 though it's ABR and sort of "hibernates" when long time no change in input scene Apr 03 21:49:37 when it does (may take up to a minute it seems) then bandwidth of stream goes down from ~2Mb/s to 500kb/s and a "framerate" like 1/s and it takes like 3s to ramp up to narmal operation again. Free motion detection, simply watch bandwidth \o/ ;-D Apr 03 21:49:48 sicelo: ^^^ Apr 03 21:50:14 cope? Apr 03 21:51:17 works fine Apr 03 21:54:12 prolly you could reduce latency further by tweaking (or omitting) rtpjitterbiffer Apr 03 21:54:45 for my purposes it's absplutely fine Apr 03 21:55:06 absolutely, even Apr 03 21:56:15 gotta consider how to deal with maemo-camera though Apr 03 21:59:08 prolly needs some tweaking of dbus stuff, or maybe simply not starting camera during system boot may do the trick Apr 03 22:00:33 then OTOH I vaguely recall that without camera getting started at least once since boot, the videa had abysmal (or no) white balance done Apr 03 22:16:56 also on N900 the gstreamer process doesn't get killed on teardown of connection - gotta come up with some smart(er) job management Apr 03 22:21:56 thanks for the explanation. Apr 03 22:36:45 yw :-) thanks for your interest Apr 03 22:37:52 ;) Apr 03 22:54:07 did I share that nice deep-insight "[bash] how to handle signals" stuff? Apr 03 22:56:17 bottom line: when your script catches a signal that would normally make it abort, you MUST make the script terminate itself by sending that very signal to $self, to let outer shell wrappers know whether to continue or to abort Apr 03 22:57:04 I.E do NOT use a simple `exit` Apr 03 23:23:40 How the shell handles ^C (SIGINT) and why: http://www.cons.org/cracauer/sigint.html Apr 03 23:24:34 TL;DR: trap 'rm -f $TMP ; trap 2 ; kill -2 $$' 1 2 3 13 15 **** ENDING LOGGING AT Thu Apr 04 02:59:57 2019