Why is it that I can post the attached mp4 but not the source as a gif?

To make the mp4 I encoded the gif in handbrake, which actually made increased the file size but reduced the dimensions.

Source gif:  728*408, 785.5 KiB
Encoded mp4: 640*360, 836.7 KiB

all 18 comments

sorted by: hot top controversial new old
[–] 20 points 1 year ago* (last edited 1 year ago) (4 children)


EDIT: For real though, you can always just hotlink embed the source like this (provided the source site allows hotlinking):

Example: ![](http://my.image.url/image.gif)

This specific image: ![](https://www.maxim.com/wp-content/uploads/2021/05/ibjtdug-imgur.gif)

If you're looking for somewhere to upload files with clear limits which are explained, I suggest catbox.moe

  • source
  • hideshow 4 child comments
  • [–] 2 points 1 year ago* (3 children)

    I'm pretty sure that pict-rs doesn't force-convert things to WebP -- the vanilla Lemmy Web UI just fails the upload, and I'm sure that it at least also does PNG and JPEG, as static images go. It might be that your client is doing a conversion to try to work around that limitation?

  • source
  • parent
  • hideshow 3 child comments
  • [–] 2 points 1 year ago (2 children)

    I only upload photos from the web interface. They all always become webp.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 1 point 1 year ago* (last edited 1 year ago) (1 child)

    Hmm. I'm certain that they've just failed on lemmy.today's vanilla Lemmy Web UI, not converted.

    goes to test

    I just created a test (non-animated) gif. Trying to upload it just fails


    that is, one can select it and try to upload it, but the Web UI never inserts the uploaded image URL in the textbox.

    Here it is on catbox.moe:

    If I convert it to a PNG, a format that pict-rs does understand, it uploads without being converted to WebP:

    Maybe it's something unique to lemmy.blahaj.zone?

    EDIT: There's an option in the docker/docker-compose.yml in the lemmy git repo showing an example of how to add an option to force pict-rs to convert everything to WebP. So my bet is that lemmy.blahaj.zone has done that:

    https://github.com/LemmyNet/lemmy/blob/main/docker/docker-compose.yml

    # we can set options to pictrs like this, here we set max. image size and forced format for conversion                                                                                                                                                      
    # entrypoint: /sbin/tini -- /usr/local/bin/pict-rs -p /mnt -m 4 --image-format webp
    

    EDIT2: @Ada@lemmy.blahaj.zone would know.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 13 points 1 year ago* (last edited 1 year ago)

    On size, Lemmy uses pict-rs to handle image uploads. There's a per-instance-settable byte limit max on the max file size that can be uploaded to a pict-rs instance. I've got no idea whether it supports animated gifs.

    EDIT: So, a bit of experimentation later, Pict-rs does take WebM. And WebM can contain AV1-encoded stuff, which can be lossless. But AV1 doesn't appear to be optimized for GIF-style flat color images, the way MNG and APNG are. Still, you can get a (larger) file which a pict-rs instance will accept as long as it doesn't hit the filesize limit, which represents the video in the GIF file without loss:

    $ stat --format=%s ibjtdug-imgur.gif
    804394
    $ ffmpeg -i ibjtdug-imgur.gif -c:v libaom-av1 -aom-params lossless=1 ibjtdug-imgur-av1-lossless.webm
    $ stat --format=%s ibjtdug-imgur-av1-lossless.webm
    1856545
    $
    

    That slightly more than doubles the filesize.

    That being said, I will point out that GIF itself really isn't a great format for this. Like, the reason that many codecs won't do well with this is because they deal poorly with dithered images. The original data (the original original data, pre-GIF-encoding) isn't dithered, and got smashed down to 256 colors and an ordered dither when it was encoded as a GIF, and it'd probably be preferable to not dither it; using that would probably result in a better-quality and smaller video.

    EDIT2: It's too bad that pict-rs doesn't support APNG, which it looks like can clamp down on it further:

    $ ffmpeg -i ibjtdug-imgur.gif ibjtdug-imgur.apng
    $ stat --format=%s ibjtdug-imgur.apng
    995418
    

    That's still enlarging it compared to the GIF. But then if we give it a pass through apngopt:

    $ apngopt ibjtdug-imgur.apng ibjtdug-imgur-opt.apng
    $ stat --format=%s ibjtdug-imgur-opt.apng
    512106
    

    And now it's 36% smaller than the original GIF. But presently, pict-rs doesn't accept APNGs.

    We can upload it to catbox.moe, though:

    EDIT3: I also apparently yanked the loop setting off somewhere in there, but I'm sure that it's technically possible to have an APNG loop.

    EDIT4: Ah, apparently one needs the -plays 0 flag for infinite looping on ffmpeg; ffmpeg apparently doesn't read that from the source:

    $ ffmpeg -i ibjtdug-imgur.gif -plays 0 ibjtdug-imgur-plays.apng
    $ apngopt ibjtdug-imgur-plays.apng ibjtdug-imgur-plays-opt.apng
    

    And there we go:

    EDIT5: It looks like, while the stock Lemmy Web UI displays WebM and one can see the one I posted on lemmy.today's pict-rs instance above along with the two APNGs on catbox.moe, the alternative Alexandrite Web UI apparently omits showing WebMs. So I don't know what the client support matrix is for all this


    gotta worry about pict-rs, the client, and if it's a Web client, the Web browser accessing the client.

    EDIT6: Piefed's Web UI looks like it's fine with displaying both the APNGs and the WebM. Searching for a public mbin server


    apparently fedia.io stopped allowing anonymous access


    based on kbin.earth, it looks like mbin's Web UI doesn't show any of the images inline, though it does provide links to them (which may be a good idea from a privacy standpoint. I've pointed out before that external inline images have privacy implications for users).

    EDIT7: Hmm. While pict-rs doesn't accept uploads of APNG on lemmy.today, looking at the pict-rs crate, it says that it does support APNG (and GIF, for that matter).

    Supported ext file extensions include apng, avif, gif, jpg, jxl, png, and webp.

    "Curiouser and curiouser", said Alice.

    EDIT8: And based on the docker/docker-compose.yml in the Lemmy git repository, the version of pict-rs being used with Lemmy should support it.

    https://github.com/LemmyNet/lemmy/blob/main/docker/docker-compose.yml

    image: asonix/pictrs:0.5.17-pre.9

    It looks like pictrs's APNG support should have been done as of commit 719626de07cfed793bf6b2b812ce988c8f6acd4c. pict-rs's 0.5.17-pre.9 tag was commit 2c84bb20923f6562c79d0684dc8736965e70a3da, much later, so it should be in. Dunno; maybe there's some restriction in Lemmy that I couldn't find quickly.

    EDIT9: And it's not that it was only recently that Lemmy pulled in that version of pict-rs. On the pict-rs repo, checking which releases had the pict-rs APNG support:

    $ git tag --contains 719626de07cfed793bf6b2b812ce988c8f6acd4c
    

    The output there includes v0.5.7. In the lemmy repo:

    $ git blame docker/docker-compose.yml|grep asonix
    426684d90f docker/docker-compose.yml     (Dessalines       2025-02-10 17:27:22 -0500  64)     image: asonix/pictrs:0.5.17-pre.9
    $ git blame docker/docker-compose.yml 426684d90f~|grep asonix
    027017b0a8 docker/docker-compose.yml     (renovate[bot]    2024-06-15 06:53:11 -0400  78)     image: asonix/pictrs:0.5.16
    $ git describe --tags 426684d90f
    1.0.0-alpha.0-10-g426684d90
    $ git describe --tags 027017b0a8
    0.19.4-13-g027017b0a
    $
    

    So while they did pull in pict-rs 0.5.17-pre.9 pretty recently, and it's only to be in the 1.0 release (and lemmy.today is running 0.19.11), they pulled in pict-rs 0.5.16, which should contain the APNG support, way back for the lemmy 0.19.4 release. That does sort of suggest that either there's a bug in Lemmy or that there's some intentional restriction that I'm not promptly finding in the Lemmy codebase to prevent GIF and APNG uploads.

  • source
  • [–] 8 points 1 year ago (3 children)
  • [–] [S] 6 points 1 year ago (2 children)

    I mean yeah but having to use handbrake to encode it is less than great.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 4 points 1 year ago (1 child)

    I feel like something’s gone very wrong if the MP4 is dimensionally smaller but has a larger file size than the GIF

  • source
  • parent
  • hideshow 1 child comment
  • [–] 1 point 1 year ago

    The original video was not dithered.

    GIF is a format that was originally designed to do static images with flat colors. (Or, I think dithered...I know that PNG definitely can encode ordered dithers efficiently, and this is an ordered dither, rather than something like a Floyd-Steinberg dither).

    GIF cannot do more than 256 colors in a frame, so whoever created the GIF will have, as part of the compression, caused the number of colors to be reduced, with dithering used to try to compensate for the lack of colors. That's why it looks "grainy".

    Most video compression codecs are not optimized for compressing dithered images, because video normally doesn't look like that.

    If you took the original, pre-GIF-compression video, which wasn't dithered down, and compressed it with something like MP4, you'd probably get rather better quality per byte size than you do with GIF. But once the video has been passed through GIF's compression...shrugs

  • source
  • parent
  • [–] 5 points 1 year ago* (6 children)

    I'm on @jerry@infosec.exchange 's cursed Mbin instance, and I can upload GIFs as images. The upload filesize limit here is 6,000,000 bytes with the drawback that I can't upload in better formats like MP4 or WebP.

    a GIF of I think South Park: The Stick of Truth's difficulty selection, where the player's skin color makes the game more difficult; "easy" is white, "very difficult" is black

  • source
  • hideshow 6 child comments
  • [–] 9 points 1 year ago (5 children)

    I can increase that if you like.

  • source
  • parent
  • hideshow 5 child comments
  • [–] 1 point 1 year ago (3 children)

    5.71MB is plenty generous. I'd give up 5MB of that if we could have anonymous browsing again. I can't recommend Mbin to people if they have to log in to see anything. Would converting all uploads to WebP lighten the load?

  • source
  • parent
  • hideshow 3 child comments
  • [–] 3 points 1 year ago (2 children)

    I reenabled anonymous access and predictably the site started getting hammered immediately. I blocked a bunch of broad IP ranges that were the biggest sources but I’m sure I’ve probably blocked some legit people.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 1 point 1 year ago

    Holy crap, that sucks! Why can't those scrapers just scrape each other? I'm sorry, I didn't want to pressure you to open up to that kind of abuse. I want to think of ways to help this situation, but you're probably 10 steps ahead of me. Thank you for trying so hard.

  • source
  • parent
  • [–] 1 point 1 year ago

    Oh, is that why most mbin sites have gone registration-only?

    kagis

    https://joinmbin.org/releases/

    Create documentation for setting up anubis to protect mbin by @BentiGorlich in https://github.com/MbinOrg/mbin/pull/1706

    I expect that this is going to be something of a whack-a-mole game


    I saw a post the other day about how some scrapers had started completing Anubis challenges (though it was apparently via doing the work, and I imagine that the cost could just be increased as appropriate).

  • source
  • parent
  • [–] 3 points 1 year ago

    I've pretty much given up on Lemmy media uploads and I default to hotlinking these days.

    Catbox.moe is a popular place for uploading for this purpose. Alternatively, I decided to roll my own for various reasons and you can DM me if you're interested in testing the platform.

  • source