[Standards] Proposed XMPP Extension: File metadata element
jonas at wielicki.name
Thu Nov 19 18:41:00 UTC 2020
On Donnerstag, 19. November 2020 16:38:54 CET Marvin W wrote:
> On 19.11.20 15:29, Jonas Schäfer wrote:
> > - I do not like the dimensions element carrying two values. I suggest to
> > use separate width/height elements. Same motivation as for 1st normal
> > form for databases.
> Agree. Not sure where I copied that from, but splitting in width/height
> definitely makes sense.
> Also, might even be worth considering adding something for 3d scene
> files, but that's probably future talk for the next few years ;)
> > - Did you consider using the `flick` unit for the duration, instead of
> > milliseconds? See for example https://github.com/facebookarchive/Flicks
> I was originally using seconds, but then decided that seconds are too
> low accuracy for properly displaying a slider or progress bar when the
> audio/video is just a few seconds. I can't imagine any usecase where
> flick accuracy would be needed, but if there are, I'd rather like to
> move those in a separate field. The <length/> is mostly for something
> that can actually be displayed to normal users, and flick unit accurate
> numbers certainly can't, except when rounded to millisecond accuracy or
> less ;)
Right, that’s all I wanted -- consideration. I didn’t expect this to be
useful. Milliseconds *feels* arbitrary, but rationally I think it is a good
(Things going on in my head: "seconds would be prefix-less, but for
appropriate precision, decimal digits would be required -> float support";
"but how about using fixed-point?"; "yeah, then we can go with milliseconds
right away instead of bothering to write *that* down properly"; "but
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the Standards