04:41 <esden> For those curious, there is some more progress on the Glasgow assembly front :D https://chaos.social/@esden/102267109659152689

04:54 <TD-Linux> whitequark, juuuust barely. vimeo started using it today

04:55 <whitequark> TD-Linux: yeah that's why i'm asking

04:55 <whitequark> uh, i think i already went over this

04:55 <whitequark> but if i want to encode straight rgb at highest possible quality with it

04:55 <whitequark> i have to upsample, right

04:55 <TD-Linux> do you want lossless, or just high quality lossy

04:55 <whitequark> ideally lossless

04:56 <TD-Linux> we don't implement lossless, but we do implement 4:4:4 rgb which wasn't true last time you asked

04:56 <whitequark> 4:4:4 rgb might be good enough

04:56 <whitequark> i'd have to, well, look at it

04:56 <whitequark> the other option is to encode into a gif

04:57 <whitequark> and you can probably imagine what a 4-hour gif looks like

04:57 <TD-Linux> oh lol yeah this is going to be 10000000x better

04:57 <whitequark> possibly the second most hostile video format to use for anything

04:57 <TD-Linux> try it and let me know how it goes

04:59 <whitequark> is there anything I should tweak

04:59 <whitequark> the frames are tiny

04:59 <TD-Linux> --quantizer. lower is better quality

05:00 <whitequark> uh hang on, looking at examples/

05:02 <whitequark> a bit lost in the src/bin

05:02 <whitequark> are there uhm. docs

05:07 <whitequark> TD-Linux: is that just SpeedSettings::from_preset?

05:21 <sorear> multipart/x-mixed-replace

05:38 <TD-Linux> whitequark, whoops sorry was afk

05:38 <TD-Linux> examples/ is more like how to use the api

05:38 <TD-Linux> the bin just has --help basically

05:38 <TD-Linux> the README has some basic usage examples

05:38 <TD-Linux> actually for your use case 4:4:4 YUV should be fine, possibly better than RGB

05:38 <TD-Linux> what format is your video starting in?

05:45 <TD-Linux> I think the C api documentation is actually better than the rust atm... https://github.com/lu-zero/crav1e/blob/master/src/lib.rs

05:47 <TD-Linux> also I *just* landed a patch that improves cargo doc a lot

05:48 <whitequark> TD-Linux: RGB 565

05:48 <TD-Linux> yeah just use plan ol' YUV 4:4:4

05:48 <whitequark> because browsers like yuv more?

05:50 <TD-Linux> yes, but also because it compresses better (YUV decorrelates)

05:50 <TD-Linux> only reason to use RGB is to reduce quantization error during the conversion. but that error is much smaller than RGB565 quantization steps

05:52 <whitequark> ahh

05:52 <whitequark> thank

05:58 <sorear> in what ways is 4:4:4 rgb not lossless?

06:00 <TD-Linux> rav1e doesn't implement av1's lossless mode. it's like opus vs flac

06:01 <whitequark> is that planned?

06:01 <TD-Linux> yes, though it's very high priority right nw

06:07 <whitequark> not very high?

06:08 <TD-Linux> *not very high yes

06:08 <TD-Linux> patches welcome but I don't know of anyone currently writing a patch for it

12:32 <marcan> <@whitequark> possibly the second most hostile video format to use for anything <- did I ever show you bomb.gif?

12:32 <marcan> http://mrcn.st/t/bomb.gif

12:33 <marcan> 3MB gif, works fine in a browser, but if you try to run it through ImageMagick or the like, it'll slowly OOM your machine

12:33 <marcan> I used it to DoS a particularly idiotic service we were forced to use at a particular old job I had, until they gave up and disabled gif support (I guess fixing it was too hard?)

12:34 <marcan> best part was how they ran the production instance and their public website all on the same machine/instance, so DoSing it took down the whole thing. quality engineering.

12:36 <marcan> I just ran it through convert and it's 3 minutes in and 10% RAM used (which is 3GB)

13:07 <karlyeurl> That a… bunch of frames.

13:25 <karlyeurl> (*That's)

15:40 <karlyeurl> It took 2h30 for gimp to open the 100001 frames, then the RAM use spiked up to 70% (of 8GB), then it segfaulted. That was a fun Friday afternoon distraction.

21:49 <TD-Linux> technically bomb.gif is possible with any other video format. it's just that normal video players know that they can't load all frames into memory, generally.