Re: [dev] [farbfeld] version 1 release

From: Marcel Rodrigues <marcelgmr_AT_gmail.com>
Date: Thu, 7 Jan 2016 19:37:16 -0200

Last time I wanted to create some animations the API of both libvpx
and ffmpeg looked so unfriendly (too much boilerplate required and too
little documentation/examples provided) that I ended up writing a GIF
encoder from scratch [0]. GIFs have some serious limitations, such as
the 256 color limit and the fact that GIF players can't pause or seek,
but for situations where these issues don't matter it's a decent
format IMO. I use it to generate animations of terminal sessions [1].
WebM lossy compression wouldn't be good for it anyway.

[0] http://repo.or.cz/gifenc.git
[1] http://repo.or.cz/congif.git

2016-01-06 19:20 GMT-02:00 FRIGN <dev_AT_frign.de>:
> On Wed, 6 Jan 2016 11:55:26 -0800
> "Leander S. Harding" <lsh_AT_lsh.io> wrote:
>
>> Modest proposal: let us define an animated-farbfeld format as a
>> tarball of sequentially-name farbfeld files, perhaps with a metadata
>> file containing frame times and looping information.
>
> To be honest, I am kind of on the webm-bandwagon for animations.
> Animated gifs served the web well for over 10 years, but it's just
> clear that animations served with image formats just won't cut it.
> the problem is that compression algorithms won't be able to handle the
> data as well as a video encoder could.
>
> It takes more thought to come up with a suckless video format, and to
> be honest, I don't find this area to be as exciting or useful as the
> area of image editing.
>
> Although I think your proposal was kind of creative, let's really
> focus on the image format here.
>
> Cheers
>
> FRIGN
>
> --
> FRIGN <dev_AT_frign.de>
>
Received on Thu Jan 07 2016 - 22:37:16 CET

This archive was generated by hypermail 2.3.0 : Thu Jan 07 2016 - 22:48:11 CET