Hello All!

I had a visitor this morning:

https://kolico.ca/mpg/a-deer-VID_20210410_075723.mp4

There were actually two of them, but I only had the mind to try
and film something when the 1st one had already walked by.



--- OpenXP 5.0.49
* Origin: Mobile? ASIAN_LINK https://preview.tinyurl.com/y6rwskq (2:221/1.58)

-={ 2021-04-10 13:54:43.739887657+00:00 }=-

Hey August!

https://kolico.ca/mpg/a-deer-VID_20210410_075723.mp4

'mplayer -vo fbdev2' on the console works but was a bit choppy. I tried playing with a cache in hopes to improve it but it didn't so then I downloaded it and played it locally. Bingo! Nice and smooth. Fullscreen too. :-)

Too slow of a connection. wget shows 706 KB/s. An old fashioned mpeg2 probably would be better for streaming. Just saying ...

Life is good,
Maurice

... Gemæne sceal maga feoh.
Wealth should be shared by kinsmen.
--- GNU bash, version 5.1.4(1)-release (x86_64-motorshed-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Hi Maurice,
...Greets from my Telegram app!

-={ 2021-04-10 13:54:43.739887657+00:00 }=-

Hey August!

https://kolico.ca/mpg/a-deer-VID_20210410_075723.mp4

'mplayer -vo fbdev2' on the console works but was a bit choppy. I tried playing with a cache in hopes to improve it but it didn't so then I downloaded it and played it locally. Bingo! Nice and smooth. Fullscreen too. :-)

Too slow of a connection. wget shows 706 KB/s. An old fashioned mpeg2 probably would be better for streaming. Just saying ...

Life is good,
Maurice

... Gem?ne sceal maga feoh.
Wealth should be shared by kinsmen.

Thanks for the heads-up on that. I had a feeling that maybe I should have built a media "container" in html for it. Directly from the isp, it plays very choppy for me too even on DSL.

Firefox doesn't give me and option to right-click/download it either.

Ciao!
/|ug (https://t.me/aabolins)

... Searchable Help for OXP https://openxp.kolico.ca
--- tg BBS v0.6.4
* Origin: Fido by Telegram BBS from Stas Mishchenkov (2:460/256)

-={ 2021-04-10 17:48:03.371541649+00:00 }=-

Hey August!

Thanks for the heads-up on that.

You're welcome.

Firefox doesn't give me and option to right-click/download it
either.

Compared to the rest of the GUI based browsers, firefox is the best. At the moment there are issues with firefox and it's required dependencies so I am sticking with console based commandline tools which happens to suit me just fine thank you very much. :-)

What did you use to shoot the mp4? I got the impression it was either a smart phone or tablet. Whatever it did a nice job of it.

Life is good,
Maurice

... Yldo beoð on eorðan æghwæs cræftig.
Old age has power over everything on earth.
--- GNU bash, version 5.1.4(1)-release (x86_64-motorshed-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Hello Maurice!

** On Saturday 10.04.21 - 17:48, you wrote to:

-={ 2021-04-10 17:48:03.371541649+00:00 }=-

^^^^^^^^^

Down to the �sec?

Firefox doesn't give me and option to right-click/download
it either.

Compared to the rest of the GUI based browsers, firefox is the best.

I actually managed to get a right-click save-as option when I
visited this message on a webby-based bbs. :D

At the moment there are issues with firefox and it's
required dependencies so I am sticking with console based
commandline tools which happens to suit me just fine thank
you very much. :-)

I don't blame you. There is a certain control and power when
commanding things via commandline. It's not called commandline
for nothing! :)

What did you use to shoot the mp4? I got the impression it
was either a smart phone or tablet. Whatever it did a nice
job of it.

Blackberry Q10.
Video: 1080p@30fps
Frame: 1280x720

If the window was cleaner, the image would have been much
better. I leaned the BB against the window and panned the scene
while the top part of the BB was touching the window so that I
could still swivel the device.
--
../|ug

--- OpenXP 5.0.49
* Origin: Mobile? ASIAN_LINK https://preview.tinyurl.com/y6rwskq (2:221/1.58)

Hello Maurice!

https://kolico.ca/mpg/a-deer-VID_20210410_075723.mp4

'mplayer -vo fbdev2' on the console works but was a bit choppy. I tried playing with a cache in hopes to improve it but it didn't so then I downloaded it and played it locally. Bingo! Nice and smooth.
Fullscreen too. :-)

Yes.. testing it on a widescreen laptop, the result DOES look
pretty good.

Streaming directly from the link sucked for me too. Even with
DSL, my top speed is usually 650Kbps, and the result was stop-n-
go. Not nice.

Too slow of a connection. wget shows 706 KB/s. An old
fashioned mpeg2 probably would be better for streaming.
Just saying ...

At about 15MB and 15sec, 1MB/sec is a pretty rich expectation
for a stream. A down-conversion for this kind of stuff is
probably a good idea.

Funny note: having filmed the scene on my BB, I really had no
way to "send" the file to my server unless I were to email it to
myself first. But that would have consumed 15MB (+30% for mime
encoding) going up, and another 15MB coming down. So, no thanks.
Instead, I used Bluetooth to send it to a newer laptop that I
have. From there, I copied it onto a USB stick. Form there, I
was able to get it on the other laptop that I prefer! From
there, it went up to the server via FTP.

--
../|ug

--- OpenXP 5.0.49
* Origin: Mobile? ASIAN_LINK https://preview.tinyurl.com/y6rwskq (2:221/1.58)

-={ 2021-04-10 22:57:51.962196849+00:00 }=-

Hey August!

-={ 2021-04-10 17:48:03.371541649+00:00 }=-
^^^^^^^^^

If you count the decimal places it is 10^-9 which is nanoseconds. However in terms of accuracy it is impossible for anything I have to get better than 10's of nanoseconds under ideal conditions and I seriously doubt that given dedicated gigabit networks to sync with ntp. In that case I'd be surprised if it better than 10's of microseconds. Given the internet and ntp servers out there in the cold, cruel world I'd be comfotable saying millisecond accuracy. No doubt in my mind that everything here agrees with up to the second accuracy which is overkill for fidonet messaging. The reason for the nanosecond display is for uniqueness of messages for a potential MSGID upgrade when the time comes ... if indeed it comes. I am a good boy scout - be prepared is the motto they live by or so I am led to believe.

I actually managed to get a right-click save-as option when I
visited this message on a webby-based bbs. :D

I use a text browser with no mouse for that. The 'd' key provides that functionality.

Blackberry Q10.
Video: 1080p@30fps
Frame: 1280x720

Definetly good enough for any usage I might have for such a thing. I've run across a few so-called webcams (usb 3.0) that claim 120fps although those are way too expensive to even consider using as a webcam or the such. However the ability to do up to 60fps might be something of interest if it doesn't break the bank.

If the window was cleaner

I noticed that. No matter as I took that into account. At first I thought your lens needed cleaning until you panned following the deer and the obvious dirty spot never moved with the camera. Time to think about spring cleaning. ;-)

Life is good,
Maurice

... A hafað longunge se þe on lagu fundað.
He ever has a longing who sets out on the sea.
--- GNU bash, version 5.1.4(1)-release (x86_64-motorshed-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

-={ 2021-04-10 23:24:18.487612181+00:00 }=-

Hey August!

Yes.. testing it on a widescreen laptop, the result DOES look
pretty good.

From what I saw on a 24" widescreen monitor I wouldn't be surprised.

Streaming directly from the link sucked for me too.

You need a better connection for that, especially for x264 live streams. Perhaps 720p might work best for this idea and/or a mpeg2 instead. Given that usb 2.0 was good enough for streaming DVDs then mpeg2 on that particular connection might be just what the doctor ordered.

A down-conversion for this kind of stuff is probably a good idea.

That can be done on-the-fly these days. Definetly something to inquire about.

Life is good,
Maurice

... Onwald mæg wel reccean se þe ægðer ge hiene habban con ge wiðwinnan.
He wields power well who can both hold and resist it.
--- GNU bash, version 5.1.4(1)-release (x86_64-motorshed-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Hello Maurice!

** On Saturday 10.04.21 - 22:57, you wrote to me:

-={ 2021-04-10 17:48:03.371541649+00:00 }=-
^^^^^^^^^

If you count the decimal places it is 10^-9 which is nanoseconds.

Amazing.

...The reason for the nanosecond display is for uniqueness
of messages for a potential MSGID upgrade when the time
comes ... if indeed it comes. I am a good boy scout - be
prepared is the motto they live by or so I am led to
believe.

For msgid purposes why not just generate a 6 to 9 character hash
based on the content of the message? That would ALWAYS be
unique and never repeat for a l-o-n-g time.

The current approach for msgid has been to have serial number.
But why can't it be a simple hash?

FSC-0033 of June 11, 1989 proposes and interesting version for
msgid:

^AFMSGID:DDDYYHHMMSSLLNNNNOOOOPPPP[ZZZZ][Domain]

But I think progams today stick with the 8-char hex form. It
would be hard to get existing systems to work with anything
outside of that format now.

Synchronet systems have come up with another unique approach to
the MSGID line which seems to cooperate with existing systems
quite well.

I use a text browser with no mouse for that. The 'd' key
provides that functionality.

I hear that you use text-based on pretty much everything these
days.

..and the obvious dirty spot never moved with the camera.
Time to think about spring cleaning. ;-)

That window was the worst. There is a 15 ft drop to the ground
outside that particular window. The only way to clean it is to
disassemble the window from the inside. That's a lot of work. I
haven't cleaned that one for years.

--
../|ug

--- OpenXP 5.0.49
* Origin: Mobile? ASIAN_LINK https://preview.tinyurl.com/y6rwskq (2:221/1.58)

*** Quoting August Abolins from a message to Maurice Kinal ***

That window was the worst. There is a 15 ft drop to the ground
outside that particular window. The only way to clean it is to
disassemble the window from the inside. That's a lot of work. I
haven't cleaned that one for years.

We tried the Windex garden hose attachment a few years back. It worked... okay. Certainly not as great as cleaning them by hand, but better than when we started.

https://www.canadiantire.ca/en/pdp/windex-outdoor-multi-surface-concentrated-c leaner-0532078p.html


Jay

... Beat inflation - steal!

--- Telegard v3.09.g2-sp4/mL
* Origin: Northern Realms | 289-424-5180 | bbs.nrbbs.net (1:229/664)

-={ 2021-04-11 03:20:24.695191775+00:00 }=-

Hey August!

For msgid purposes why not just generate a 6 to 9 character hash
based on the content of the message? That would ALWAYS be
unique and never repeat for a l-o-n-g time.

The method I am thinking should never repeat and should be good up to -={ 2147485547-12-31 23:59:59.999999999+00:00 }=-. That is over 2 billion years from now.

Currently I am just using the hex representation of an unsigned 32-bit unixtime but there is just me and I can't produce more then one MSG within minutes, nevermind seconds and the serial number generated is unique up to -={ 2106-02-07 06:28:15+00:00 }=-. Thus the largest unique serial number possible is ffffffff. For signed 32-bit integers -={ 2038-01-19 03:14:07+00:00 }=- is the end of the line and will produce a MSGID serial number of 7fffffff which is the largest hex value for signed 32-bit integers.

If I am not mistaken -={ 2106-02-07 06:28:15+00:00 }=- is the upper limit for Synchronet systems or at least that is what I was told. When I pay attention to it I have noticed the serial numbers look very familiar to me.

Your serial number for the MSG I am replying to yields -={ 2097-03-19 18:09:50+00:00 }=- which is obviously not a time based generated serial number and definetly not a 32-bit signed integer.

I hear that you use text-based on pretty much everything these
days.

Since the beginning, which for me was back in the late 1980's on VAX/VMS. Solaris was the first GUI I ever ran across sometime around 1989-ish if I am remembering correctly. For VAX/VMS Fortran (F77) was the compiler of choice while for Solaris it was C all the way which has taken me up to and including today as I upgrade to gcc-10.3.0 as we speak. :-)

That window was the worst. There is a 15 ft drop to the ground
outside that particular window. The only way to clean it is to
disassemble the window from the inside. That's a lot of work. I
haven't cleaned that one for years.

I hear you. I am getting too old for that sort of thing. Mind you I have no windows that high up. All mine I can reach without a ladder.

Life is good,
Maurice

... Æghwilc ðing þe on þys andweardan life licað lænu sindon.
Everything which is pleasing in this present life is on loan.
--- GNU bash, version 5.1.4(1)-release (x86_64-motorshed-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Hi August,

On 2021-04-10 20:58:00, you wrote to Maurice Kinal:

For msgid purposes why not just generate a 6 to 9 character hash
based on the content of the message? That would ALWAYS be
unique and never repeat for a l-o-n-g time.

There are those moderator messages that stay the same for ages...

The current approach for msgid has been to have serial number.
But why can't it be a simple hash?

A good secure hash, needs a lot of cpu to be calculated.

Synchronet systems have come up with another unique approach to
the MSGID line which seems to cooperate with existing systems
quite well.

It isn't according to the standard, which might cause some problems on other systems.

And I think it went like this: They miss used the MSGID to store some internal information for their messagebase, and came up with an excuse afterwards, when it was difficult to correct.

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Hello Wilfred!

** On Sunday 11.04.21 - 13:05, you wrote to me:

For msgid purposes why not just generate a 6 to 9
character hash based on the content of the message? That
would ALWAYS be unique and never repeat for a l-o-n-g
time.

There are those moderator messages that stay the same for
ages...

Not if the hash includes the entire msg and the date posted.

The current approach for msgid has been to have serial number.
But why can't it be a simple hash?

A good secure hash, needs a lot of cpu to be calculated.

Even a simple random num generator could work. For example, the
following took less than a sec to produce:

H:\myutils>rando2
lfz$bkmcmmg36ye@jll1xpieaats

H:\myutils>rando2
7zc3i6btkuwyax2tpbh814$392c

H:\myutils>rando2
g~zys4kmp$9s0h@4jxp169j##8eskb

H:\myutils>rando2
p67v3h$vy3pdqo9t6rueljbv0qf

H:\myutils>rando2
m0s#trrv~bxjsg0f$mo29q8g$6699l

H:\myutils>rando2
$3111un9@je2dey$jwdehlzk01g

H:\myutils>rando2
q5ur8jolf#@4227~#73g99@lpy0dh@

H:\myutils>rando2
u4iouevy9yrh6~1it~2z$asr5y@

H:\myutils>rando2
cu1#0wqju$11~1lu#gklu52o9#k3v

So.. why couldn't something like that be implemented? And,
instead of limiting the "serialno" to hex chars, use the entire
alphabet and throw in some extra chars (# $ ~ % & *)

Synchronet systems have come up with another unique
approach to the MSGID line which seems to cooperate with
existing systems quite well.

It isn't according to the standard, which might cause some
problems on other systems.

I thought it was copacetic with other systems. On which ones
does it break?

And I think it went like this: They miss used the MSGID to
store some internal information for their messagebase, and
came up with an excuse afterwards, when it was difficult
to correct.

I remember something about the MSGID being referred to as a two-
part string with "origaddr" + "serialno", where "origaddr" is
intended to be a qualified "address of the originating system".

Most systems keep it simple:

z:f/n.p hhhhhhhh

And some others look like:

n.areaname@z:f/n.p hhhhhhhh

--
../|ug

--- OpenXP 5.0.49
* Origin: Mobile? ASIAN_LINK https://preview.tinyurl.com/y6rwskq (2:221/1.58)