Don't know exactly, but https://trac.ffmpeg.org/ticket/1347 looks like the ticket and http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=8f66d46... looks like the commit implementing it.

Looking at comments on https://stackoverflow.com/questions/53460876/process-gif-usi... there was only a demuxer, no parser. I'm not sure why you'd need a parser but according to https://superuser.com/a/787073 ffmpeg always treated GIFs as movies, so maybe this is a way to tell which GIFs are single images?

IIRC parsers let it reconstruct metadata from files that aren't muxed, or inaccurately muxed. For instance, you'd need one to read raw .h264 files properly into .mp4.

Not sure how that would apply to GIF.

Parsers typically are used to correctly demarcate packet boundaries in (coded) bitstreams e.g. H.264 bitstream is partitioned into NAL units and the parser assembles all relevant units for a single frame/slice so that the decoder gets everything it needs to decode that sample, nothing more, nothing less.

Well I should hope it does more by now because that's not enough information to mux an H.264 stream. You need to recover PTS/DTS offsets, keyframe types, SPS, etc.

> not enough information to mux an H.264 stream.

The parser is inserted after demux and before decode.

Yes, xPS are also located and decoded. My comment wasn't meant to be an enumeration. Specific tasks depend on the complexity of the bitstream syntax.