https://kolico.ca/mpg/a-deer-VID_20210410_075723.mp4
-={ 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.
Firefox doesn't give me and option to right-click/download it
either.
-={ 2021-04-10 17:48:03.371541649+00:00 }=-^^^^^^^^^
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.
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 ...
-={ 2021-04-10 17:48:03.371541649+00:00 }=-
^^^^^^^^^
I actually managed to get a right-click save-as option when I
visited this message on a webby-based bbs. :D
Blackberry Q10.
Video: 1080p@30fps
Frame: 1280x720
If the window was cleaner
Yes.. testing it on a widescreen laptop, the result DOES look
pretty good.
Streaming directly from the link sucked for me too.
A down-conversion for this kind of stuff is probably a good idea.
-={ 2021-04-10 17:48:03.371541649+00:00 }=-
^^^^^^^^^
If you count the decimal places it is 10^-9 which is nanoseconds.
...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 use a text browser with no mouse for that. The 'd' key
provides that functionality.
..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.
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.
I hear that you use text-based on pretty much everything these
days.
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.
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?
Synchronet systems have come up with another unique approach to
the MSGID line which seems to cooperate with existing systems
quite well.
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.
There are those moderator messages that stay the same for
ages...
Not if the hash includes the entire msg and the date posted.
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:
lfz$bkmcmmg36ye@jll1xpieaats
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
Not if the hash includes the entire msg and the date posted.
Ok. But the serial based ones are still better. ;)
H:\myutils>> rando2
lfz$bkmcmmg36ye@jll1xpieaats
Those aren't 32 bit.
there's always a change of a collision within 3 years.
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".
No: "... address for the originating network"
^^^^^^^
Then the synchronet version adds some added uniqueness.
H:\myutils>> rando2
lfz$bkmcmmg36ye@jll1xpieaats
Those aren't 32 bit.
Ah... so the "serialno" part *must" be 8-char? Then rando could
still work like so:
yZn=ZRG-
there's always a change of a collision within 3 years.
Yes.. I've suspected that could be problematic.
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".
No: "... address for the originating network"
^^^^^^^
Ah.. that little word "for" makes a big difference. :
Then the synchronet version adds some added uniqueness.
^^^Ah... so the "serialno" part *must" be 8-char? Then rando could
still work like so:
You should read the fts document on it! ;)
"...The serial number may be any eight character hexadecimal number"
H:\myutils>> rando
yZn=ZRG-
Your suggestion is perfectly valid but to be honest I still
believe that a 32-bit hex value for the unixtime or rfc-868
(seconds since 1900) is the best choice for uniqueness over
the longest span which is much greater than the 3 year
period required by the current standard.
Also it adds meaning to it beyond what is capable for a
randomly generated serial number. Unfortunetly it has a
shelf life that is quickly running out whereas the random
one doesn't.
But what if two or more systems process messages at exactly the
same time of the day?
It won't matter since two or more systems will have two or more unique addresses..
MSGID: 1:153/7001.0 01234567
MSGID: 1:153/7001.1 01234567
..As for random collisions there isn't any guarentee that
either of the above two systems won't create a collision
within three years no matter how remote that possibility
is..
whereas the serial number created by the number of seconds
since 1970|1900 should NEVER create a collision within it's
lifetime, 2106 in my particular case..
..Adding more characters doesn't add meaning or additional
functionality to it.
I thought the concern was that some dupe-check implementations
only use the "serialno" part.
And, now that we've totally bored the vast number of ASIAN_LINK
listeners, we should probably move to something less technical.
H:\myutils>> rando
yZn=ZRG-
An 8-char series where each char can be [a-z]|[A-Z] = 52^8
possible strings. Add the numbers [0-9] and the possibilities
climb to 62^8. Throw in some special char options, and the
number climbs even higher. That approach far surpasses the hex
choice at 16^8.
Also it adds meaning to it beyond what is capable for a
randomly generated serial number. Unfortunetly it has a
shelf life that is quickly running out whereas the random
one doesn't.
Right. Therefore, I see two +1's for the random [a-z]|[A-Z]|[0-
9] version, and atleast one -1 for the time-serial version.
I thought the concern was that some dupe-check implementations
only use the "serialno" part.
..Adding more characters doesn't add meaning or additional
functionality to it.
BUT.. you must agree that the likely hood of two rando numbers
colliding given that any of the 8 chars in the serialno part can
be [a-z][A-Z][0-9] at 62^8, is pretty unlikely.
Even a serial number based on an incremental 8 char string with [a-z][A-Z][0-9] could work too.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 371 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 174:38:38 |
| Calls: | 7,915 |
| Files: | 12,983 |
| Messages: | 5,797,649 |