mlajtos / mosaic

A tiling web browser.
MIT License
106 stars 4 forks source link

The gif of 10 MB cause a crash in the browser #49

Closed arteze closed 2 years ago

arteze commented 2 years ago

I have a 960 MB RAM capability on my computer, and the GIF of approximately 10 MB, consumes 400 MB or more in the browser, this is like 50%.

I'm using Basilisk ... The temporary solution was blocking it with uBlock.

When reporting the problem the browser they tell me that it is a bad idea to have a GIF over 1 MB.

https://forum.palemoon.org/viewtopic.php?p=221715

In Viewnior it works correctly. Anyway, if I deactivate uBlock, the problem is again.

Maybe it's better other format, such as webp/webm or mp4 on a link.

mlajtos commented 2 years ago

Hold up... I should fix promo GIF for my browser because some other browser can't handle the GIF?

GIF was a pragmatic choice – it autoplays and loops without any magic on ALL browsers and platforms. WebM is still not universally supported. One time I got a request to change embedded video from MP4 to something else because the user didn't have codecs for MP4 on his system.

I would be happy to merge PR if you have any workable solution. I don't have skill in optimizing GIFs, but I bet it can be compressed to ~2MB without any major decrease in quality.

Anyway, thank you for a good chuckle. You made my day. :)

arteze commented 2 years ago

In Basilisk, they did not give me a certain response, whether changes will be made or not, in another thread they responded with the word Wontfix, which means "no repair" and apparently maintain that decision.

I see that in the Mosaic browser this problem with the gif does not exist, and that is good, but it is not a usable browser at all, since it does not have to login and other things, really, if it was fully functional, it would stop use Basilisk. Meanwhile I'm still looking for alternatives.

I would like to know the amount of frames that the gif has, so it would be with better precision the possible memory usage that would occupy in a modern computer. I see that the resolution is Full HD, 1920x1080.

If the gif is compressed at 2 MB, the Basilisk will also not be able to handle it correctly, since it is not using any type of compression in the memory, what the browser would do is unzip and generate the raw pictures, as it is said, is for greater performance... Anyway, yes, it would be adequate to reduce it, it would take less time to download it.

I imagine that I will not be the only visitor who has a very old computer, there must be more, or in the future there could be, and for some reason find this project, and it costs them to carry the content.

I also in Firefox I had problems with mp4 codecs, in Basilisk I do not have that problem.

arteze commented 2 years ago

I was able to extract every Frame from the gif ... In total there are 458 frames.

> 458*1920*1080/1024**2
905.712890625

> 458*4*1920*1080/1024**3
3.5379409790039062

This means that if the browser uses 1 byte per pixel, the gif consumes 906 MB of RAM... Instead, if it's used 4 bytes (with alpha channel), the browser consumes 3.54 GB of RAM.

Now I am in another browser, Firefox Light 48.0, it does not show the gif, but an image comes out as if the link is broken... Anyway, it can be downloaded without problems.

shakeyourbunny commented 2 years ago

GIF is not a substitute for a movie, although I can reason why you are using a GIF for that, but if you insist on using a GIF instead of proper movie file, you cannot toss the 1080p / high FPS mp4 / webm into a movie to GIF maker and call it a day.

I did some optimization with on www.ezgif.com:

End result is that the optimized GIF has been shrunk by 90% (from 10,8 MB to 0,9 MB) and is still well readable and light on resources. This has NOTHING to do with "uhm you have not a current browser or niche browser", but this is just bad, lazy optimization.

Have fun.

Mosaic-0 0_1-optimized

PS: you can get a better quality for the gif, if you convert your mp4 file directly on www.ezgif.com and do the optimization part; especially slashing the number of frames and resizing it to 960x540 will produce a small GIF.

arteze commented 2 years ago

@shakeyourbunny The optimized gif works perfectly, and the RAM in the browser is stable.

It would be good for the current gif to be changed to the optimized.

mlajtos commented 2 years ago

That optimized GIF looks like shit, to be honest. However, smaller resolution is a good idea. Throwing frames out is not.

shakeyourbunny commented 2 years ago

I did mention that the optimized GIF does not look good. The reason is that the generated GIF by itself has already these yellow artifacts and I did wrote that a proper one should be generated by the original video.

If I had access to the original video, I could do a better job, so I suggested to visit ezgif.com or using a GIF editor for a proper one.

arteze commented 2 years ago

The problem is that gif has background noise, so it always ends up weighing more than 10 MB, with any conversion method.

Screenshot(107)

If you could remove the background noise it would become more easily.

I'm trying with a command ImageMagick... It seems that it will work.

convert $file -interpolate Average16

I also did tests with ffmpeg.

If I open the gif of 60 MB in the browser, they work perfectly without problem with the RAM. The weight varies between 30 MB and 80 MB, depending on the filter applied, the lightest are Nearest and Area.

arteze commented 2 years ago

I could reduce it to 7.5 MB, but the resolution is 320x180.

mosaic_gifsicle_ffmpeg_320_area_noma

Would it be good to change it?

mlajtos commented 2 years ago

Here is the original video as MP4:

https://user-images.githubusercontent.com/1047512/147593630-50b7b685-e5c1-4069-a0d0-d1991da28ece.mp4

arteze commented 2 years ago

I have converted the mp4 it to a resolution of 960x540, and has a weight of 2.9 MB. It works well.

Mosaic Jokes_960_gs

Bash code that I used:

n=Mosaic.Jokes
t=$((1920/2))
f=neighbor

ffmpeg -i "./$n.mp4" -vf scale=$t:-1:flags=$f ./${n}_${t}_${f}.gif

gifsicle-static -k256 -O3 -o ./${n}_${t}_${f}_gs.gif ./${n}_${t}_${f}.gif
arteze commented 2 years ago

I managed to remove the background noise, now it looks good even when it is resized by the browser.

First genre the frames in a folder, and a palette, then generate the gif from the frames and the palette... To create the gif without noise use this, paletteuse=dither=none.

n=Mosaic.Jokes
t=$((1920/2))

mkdir -pv ./mp4_frames
ffmpeg -i $n.mp4 ./mp4_frames/f%03d.png
ffmpeg -i ./mp4_frames/f%03d.png -vf palettegen palette.png
ffmpeg -i ./mp4_frames/f%03d.png -i palette.png -filter_complex "fps=24, scale=$t:-1, crop=in_w:in_h-18:0:18, paletteuse=dither=none" ./mp4_frames/${n}_${t}_nd.gif

gifsicle-static -k256 -O3 -o ./${n}_${t}_nd_gs.gif $o

Result: A gif of 2.4 MB

Mosaic Jokes_960_neighbor_nd_gs

mlajtos commented 2 years ago

The quality of the GIF is good enough – too much dithering going on, but I can live with that. (And I added full size video in MP4 as "backup".)

Thank you very much for this! I love seeing red diffs. ;)

Snímka obrazovky 2021-12-28 o 22 15 51
arteze commented 2 years ago

It was fine, I also tried another dither method, floyd_steinberg, and it looks better.

n=Mosaic.Jokes
t=$((1920/2))
f=floyd_steinberg
o=./${n}_${t}_${f}_nd.gif

if [ ! -f ./mp4_frames/f001.png ];then
  ffmpeg -i $n.mp4 ./mp4_frames/f%03d.png
fi

if [ ! -f ./palette.png ];then
  ffmpeg -i ./mp4_frames/f%03d.png -vf palettegen palette.png
fi

if [ ! -f $o ];then
  ffmpeg -i ./mp4_frames/f%03d.png \
    -i palette.png \
    -filter_complex "fps=24, scale=$t:-1, crop=in_w:in_h-18:0:18, paletteuse=dither=$f" \
    $o
fi

if [ ! -f ${o}_gs.gif ];then
  gifsicle-static -k256 -O3 -o ${o}_gs.gif $o
fi

The weight is of 5.7 MB

This time I could not upload it around here, but there is the code, in case you want to see it.

arteze commented 2 years ago

I could upload it (with filter floyd_steinberg).

Mosaic Jokes_960_floyd_steinberg_nd gif_gs