Time  Nick       Message
10:23 rubenwardy #8383
10:23 ShadowBot  https://github.com/minetest/minetest/issues/8383 -- Add formspec styling using a style[] tag by rubenwardy
19:02 sofar      for mp3/opus/ogg: the reason to add mp3 support is that for long sound tracks and music, mp3 offers the lowest size at lossy quality levels (~128kbits) and thus may offer significant download size benefits
19:03 sofar      if you want quality, ogg is best
19:03 sofar      but servers that want music tracks pay a heavy penalty now, and one that could be much less
19:09 p_gimeno   um, can't ogg compress at the same bit rates as mp3?
19:09 VanessaE   we need streaming :)
19:09 VanessaE   server should jhust tell the client "go to this URL, stream this sound"
19:09 VanessaE   -h
19:12 p_gimeno   comparing the quality of ogg and mp3 only makes sense for the same bitrates, and at low bitrates, ogg quality is superior
19:13 VanessaE   actually a better idea would cached steaming -- tell the client "go to this URL, stream this sound, and save the file for later re-use"
19:13 VanessaE   that would be the best of both worlds imhop
19:13 VanessaE   -p
19:14 VanessaE   the total bandwidth use at the server would be comparable, but there'd be basically zero extra client download time
19:16 VanessaE   and if the sound has to be cut off, either stop the sound and let the download finish in the background, or just finish the download next time the sound is needed
19:16 VanessaE   (cut off early i.e. the user has moved on to something else not needing the sound)
19:17 VanessaE   said URL could of course just be a public media server like yours or mine
19:18 VanessaE   hell even a URL could be avoided if the sound can be sourced from the media server the client is already about to download other stuff from
19:18 VanessaE   just so long as the download/playback happens in realtime.
19:21 VanessaE   one flag added to SimpleSoundSpec, and something to tell the server at connect time what files to avoid immediately downloading
19:23 VanessaE   s:server:server/client: s/downloading/transferring/
19:23 JTE        Currently I've been using the engine's sounds folder (the one used for main menu music for some reason) to play music. If the client has no appropriately named sounds installed there, they hear nothing (the server doesn't have any of the files so it doesn't pack them in with resources for download at all), but if the client has files it plays them when the server tells it to. That way, the server only needs to say "play snow village
19:23 JTE        music" and the client themselves can customize their OST to contain whatever eleven "music_village_snow.ogg", "music_village_snow.0.ogg", "music_village_snow.1.ogg", etc. files they want to hear for that event.
19:23 VanessaE   JTE: that's how technic's music player works, too.
19:23 JTE        The only downside is that the server can't provide a default fallback soundtrack, so everyone joining the server from the server list hears nothing and doesn't even know music is supposed to be there. (No error messages or anything.)
19:24 VanessaE   and is what my stream-to-cache idea is meant to address
19:24 VanessaE   I just wish I could code it.
19:24 sofar      p_gimeno: ogg is superior at high bitrates, and lossless, not low+lossy bitrates
19:25 sofar      at least from the data sources I've found
19:25 p_gimeno   sofar: lossless ogg? I haven't read of that. This comparison disagrees, anyway: this comparison disagrees: http://nigelcoldwell.co.uk/audio/
19:25 JTE        ogg vorbis is medium to high bitrate only, yes. but there is also ogg opus.
19:25 p_gimeno   oops
19:27 p_gimeno   well, when I say ogg I mean vorbis, of course - from what I read, ogg can encapsulate vorbis, opus and flac
19:27 sofar      streaming wouldn't be an option for music embedded in local games you want to play offline
19:28 sofar      so download size would still matter
19:28 sofar      but, not as important
19:28 VanessaE   sofar: well no, it wouldn't help singleplayer but in that case, who cares about download size?
19:28 JTE        I'd love for the server to be able to dictate some resources (sounds AND models) as being "download as necessary and not entirely before connecting" but that would be kind of a big deal. @@;
19:28 sofar      the player would when they download the game... :)
19:29 VanessaE   heh maybe
19:29 VanessaE   but with stream-to-cache, you could have gigs of audio on the server, and the clients wouldn't even have an extra second of download time at connect :)
19:30 sofar      which would definitely make things less enjoyable for players that have limited BW
19:30 VanessaE   why?
19:30 sofar      downloading while playing == lag
19:30 VanessaE   stream in realtime would take less bandwidth than a full download.
19:31 sofar      sure, cache-streaming, I can see that help
19:31 VanessaE   that's the idea
19:31 sofar      I wonder if the remote media server could indeed serve that up
19:31 VanessaE   download at like 20 kB/sec to get the audio in at realtime speed instead of 200 kB/sec
19:32 VanessaE   should be zero lag potential if it's done right :)
19:32 VanessaE   well, I don't see why not
19:32 VanessaE   it's not like the media server has to know what's being done with the file.
19:32 VanessaE   just so long as it's capable of resuming a partial download
19:32 sofar      the client will need to seek and read partial content
19:32 VanessaE   yeah
19:33 sofar      so libcurl needs to support seeks
19:33 sofar      well, it can already
19:33 sofar      hmm
19:33 VanessaE   client begins playback of the cached file, curl begins resuming the download, by the time he client gets to the resume point, there's already way more audio left, etc.
19:33 sofar      can't do checksum verification on it though
19:33 sofar      so you lose that, which is bad
19:33 VanessaE   meh, that can be worked around I'm sure
19:34 VanessaE   some kind of hash of the original path+filename maybe
19:34 VanessaE   or server+path+file etc.
19:35 VanessaE   or are you talking about verifying that the download isn't corrupt?
19:35 sofar      verifying that the remote media server is sending you the file you expect and not one that exploits your game
19:35 VanessaE   right
19:35 VanessaE   that's fair enough
19:36 VanessaE   but at that point, you're really just protecting against MitM right?
19:36 sofar      media server is a potential adversarial point
19:37 sofar      e.g. I run the PRMS
19:37 VanessaE   ohh
19:37 VanessaE   hm
19:37 sofar      many servers use the PRMS
19:37 sofar      I could inject false data, but right now clients would reject it entirely
19:37 VanessaE   that could pose a problem sure
19:38 VanessaE   how about handle it like is done now, but when the download completes, hash it then, in the background, and invalidate the file if it's bad?
19:38 JTE        make a bajillion mini-checksums for every 32 kb of a streaming file? heh...
19:38 sofar      JTE: yeah, that would break the compression :)
19:38 VanessaE   but then again, we don't do that now anyways do we?
19:38 JTE        oggs are already compressed
19:38 sofar      lazy loading is still possible
19:39 sofar      and I kinda like that idea
19:39 sofar      I thnk roblox does that
19:39 VanessaE   so it's not like there's any real verification once the file transfer is underway, it's not like the client hashes the file and compares it
19:39 sofar      once you have all the meshes, you can play even if you lack textures
19:40 VanessaE   sounds like something MT ought to do, then, though clearly of limited use on smaller files.
19:40 VanessaE   plus:
19:40 VanessaE   it would allow us to resolve one pain in the ass issue
19:40 VanessaE   adding new files during runtime :)
19:41 VanessaE   if a player wants a new skin, it would be really nice to let them have it then and there, instead of requiring server reboot+reconnect
19:41 sofar      that problem remains unsolved
19:41 VanessaE   I know.
19:42 sofar      because, you still need to tell the server there is new data, so it needs to reiniitialize lol
19:42 VanessaE   but with lazy loading, it would be easier to solve eventuall.
19:42 VanessaE   anyway that's secondary
19:42 VanessaE   just something that came to mind when you mentioned it
19:47 sofar      well we all want per player skin textures
19:48 sofar      maybe focus on that somehow
19:48 VanessaE   player_textures mod, homedecor_wardrobe, simple_skins, skinsdb....
19:48 VanessaE   it's a solved problem, but each has its idiosyncrasies.
19:48 sofar      no, not what I mean
19:49 sofar      what I mean is players setting a skin in their client, then logging into a game and the game uses their skin
19:49 sofar      (possibly with some validation of allowed skins of course)
19:49 VanessaE   oh yeah
19:50 VanessaE   problem is R/X-rated skins.
19:50 VanessaE   or malicious imagery in general
19:50 sofar      easy enough to make an API that allows the server owner to allow/disallow skins
19:50 VanessaE   how?  by filename?
19:50 sofar      just call some lua event on unknown hash
19:50 VanessaE   hm
19:50 sofar      and process the return value
19:50 VanessaE   so a whitelist
19:51 sofar      and only then send to other clients
19:51 VanessaE   I could see that working, but who creates the list of allowed skins?
19:51 sofar      the server admin
19:51 VanessaE   I mean, there must be hundreds of thousands out there
19:52 sofar      write a mod that server admins can use to categorize and classify skins
19:52 sofar      and one that allows specific levels only
19:52 sofar      use the httpapi to get data about the skins and share it online
19:52 sofar      I could write that part trivially
19:53 VanessaE   I could see that working I guess..  client sends a skin, whitelist isn't triggered, so it creates an "email" of sorts (like in Homedecor's mail mod) that must be approved or rejected
19:53 sofar      yep, and just falls back to a default skin defined on the server
19:53 VanessaE   that could work.
19:53 sofar      you could even allow `rp medieval` skins only that way
19:53 sofar      someone makes a new skin? upload, get pre-approval
19:54 VanessaE   all I know for now is skins are a bit of a pain in the ass right now (no 1.9 format support so they have to be cropped to 2:1 aspect, specific filenames needed, reboot needed...)
19:55 sofar      yep
19:55 VanessaE   enplus1 said he's willing to rewrite homedecor wardrobe to use simple_skins as the backend, and maybe I can talk him into adding 1.9 support, so at least some of that can be fixed.
19:55 VanessaE   tenplus1*