mpv -vo sixel is far superior to ncplayer -bpixel #1391
Comments
|
Ahhh, I think the performance advantage is coming from damage tracking internal to the media. That makes total sense. Hrmmmmm. That will not be trivial to fit into our model, though...I think we needed something like this for #1360, right? Alright, so if we brought the previous bitmap into but that can't be all. We'd expect our first frames to look roughly equivalent, but they are not. Hrmm, let's limit comparison to the first frame... |
|
ahhh yes, i noticed this the other day -- we emit a band for every color, even if the color isn't yet used. of course. let's strip those and see how things improve. |
|
@dnkl i've cut out empty bands, and it cut the total output per frame by about 40%. we still emit longer chunks than |
erp...damage tracking in this way wouldn't play nicely with moving the image :( |
|
for our first band on the first frame of
followed by
are these the same length? |
|
ok i don't understand what
there seem to be bands of very different length here. |
|
|
|
finding out some very interesting things about libsixel...it seems to emit colors which it never uses? and they definitely reproduce colors within a band...very interesting. |
|
here's a big-ass chunk of libsixel's first encoded frame |
|
Interestingly, the libsixel/mpv output appears to be much larger than our own now. |
|
we seem quite a bit faster now than we were, running e.g. |
|
i'm thinking of a new approach for colors (assuming we don't proceed with the idea in #1380):
this is a 64KiB table assuming 4x32-bit components, totally doable. |
|
trying to take this to 32x32x32 would require half a meg, but allows us to skip in terms of 8 |
|
I'm staying on my current notcurses version for a little while longer, while doing some sixel optimizations in foot. After that I'll be happy to see how the latest ncplayer is faring in foot :) |
|
i took a look at ahhh, after reading up on HSL, yes, its value here is clear. we basically get our saturation and lightness for free, and then just have to find the closest hue. either way, this is a prepartition-and-match algorithm, very similar to what i'm describing above, except i'm proposing finer partitioning, and backfitting of the determined values. what does libsixel do? |
|
it looks like libsixel uses a wholly static palette to start with (take a look at |
|
octree is a valid method. |
|
both the algorithm i proposed, and that used by Jexer, are popularity algorithms. median cut seems a better approach, though perhaps it ought be united with an HSL conversion to get the best of both worlds. |
|
ahhh, libsixel first calculates a histogram to approximate the number of colors, and if they're few enough, doesn't generate an approximate palette. so it gets the exact palette in that case, just like we do. |
|
a kohonen neural net might also be a good method |
|
So when evaluating median cut v octrees v Kohonen nets, we desire:
|
|
file:///home/dank/Downloads/Kohonen_neural_networks_for_optimal_colour_quantiz.pdf is the best read i've found on Kahonen-based quantization |
|
what if we had a constant MAXCOLOR-size array, and tracked the closest elements as we inserted, and just merged closest when full on a miss? there would be a lot of divisions.... |
|
it would appear that the Rust |
#1 0x00007ffff7f9d002 in sixel_blit (nc=0x5555555be3d0, linesize=3776, data=0x5555559ccf00, begy=0, begx=0, leny=531, lenx=944,
bargs=0x7fffffffdb20) at ../../src/lib/sixel.c:418
418 memset(stable.data, 0, sixelcount * bargs->pixel.colorregs);
(gdb) p sixelcount
$1 = 84016
(gdb) p bargs->pixel.colorregs
$2 = 1024
(gdb) p colorregs
$3 = 256
(gdb) p stable
$4 = {colors = 0, deets = 0x555555bb6770, data = 0x7fffee907010 "", table = 0x555555634be0 "\260\016\276\367\377\177",
sixelcount = 84016, colorregs = 256}I.e. |
|
But it works in XTerm... hmm |
Ah, if I bump |
|
Given int colorregs = bargs->pixel.colorregs;
if(colorregs > 256){
colorregs = 256;
}This seems like the appropriate solution (and works): diff --git a/src/lib/sixel.c b/src/lib/sixel.c
index 46169e7f8..9d117c593 100644
--- a/src/lib/sixel.c
+++ b/src/lib/sixel.c
@@ -415,8 +415,8 @@ int sixel_blit(ncplane* nc, int linesize, const void* data, int begy, int begx,
return -1;
}
// stable.table doesn't need initializing; we start from the bottom
- memset(stable.data, 0, sixelcount * bargs->pixel.colorregs);
- memset(stable.deets, 0, sizeof(*stable.deets) * bargs->pixel.colorregs);
+ memset(stable.data, 0, sixelcount * colorregs);
+ memset(stable.deets, 0, sizeof(*stable.deets) * colorregs);
if(extract_color_table(data, linesize, begy, begx, leny, lenx, &stable)){
free(stable.table);
free(stable.data); |
|
i wouldn't mess around with development branch stuff -- it's not generally ready for production -- but i'll certainly take quality investigations and bugfixes where i can find them =]. thanks, friend! |
|
i can similarly raise a coredump using |
|
this might just be from a huge allocation. |
|
we blow up at y: 178 x: 372 |
|
|
|
|
|
the coredump is remedied |
@dnkl pointed this out in #1380, but it's worth its own issue. Get two xterms up, along with a recent
mpvbuild featuring libsixel support. Run it alongsidencplayer -bpixel.mpv's superiority is obvious (we beat it with cell output, though). Get to this level of output, in both speed and quality.The text was updated successfully, but these errors were encountered: