The gif of 10 MB cause a crash in the browser

[arteze]

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]

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]

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]

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]

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:

• optimize: remove every 2nd frame: file size shrunk without noticing anything down to 5,89 MB
• reduced animation speed by about 66% to actually see anything meaningful.
• optimize: remove every 2nd frame: file size shrunk to 4,06 MB
• resize by 50% from 1920x1080 to 960x540

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.

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]

@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]

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

[shakeyourbunny]

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]

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

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]

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

Would it be good to change it?

[mlajtos]

Here is the original video as MP4:

Mosaic.Jokes.mp4

[arteze]

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

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]

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

[mlajtos]

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. ;)

[arteze]

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]

I could upload it (with filter floyd_steinberg).