[FFmpeg-devel] How to handled gzip'd files?

[Reimar Döffinger]

On Sat, Apr 02, 2016 at 07:25:46PM +0200, Nicolas George wrote:
> Le quartidi 14 germinal, an CCXXIV, Reimar Döffinger a écrit :
> > I was looking at these:
> > http://samples.mplayerhq.hu/game-formats/la-snm/grimfandango/
> > http://samples.mplayerhq.hu/game-formats/la-snm/force-commander-znm/
> > and realized that they are perfectly supported, if you first
> > run them through gunzip.
> > However there are 2 issues here:
> > 1) They are misdetected as all kinds of nonsense
> > (http://samples.mplayerhq.hu/game-formats/la-snm/grimfandango/byeruba.snm
> > as AAC for example)
> > 2) How should an ordinary user even come up with that idea?
> > 
> > Do we have a way to transparently decompress?
> > Or do you have an idea how to (relatively) easily
> > implement that?
> > Or at least a way to say "hey, I see this is gzip compressed,
> > won't try to run further autodetection"?
> > I think there (barely) enough fixed bits to reliably auto-detect
> > gzip compressed data without complex code.
> 
> Right now, we *could* do something like that: have a gunzip demuxer that
> gunzips the input octet stream and then feeds it to a slave demuxer. The
> probe function could probe gunzip signature then call the normal probe
> functions on the decompressed stream.
> 
> That would work, but that is ugly.
> 
> Less ugly: make gunzip a protocol instead of a demuxer, and require the user
> to specify explicitly "gunzip:http://.../byeruba.snm". Possibly a gunzip
> demuxer on top of that that only has a probe function and suggests the fix.

That only really works if people use ffmpeg directly and not just some
media player using libav* libraries...
Also: does such a demuxer with only probe work in a sane way?
I'd think you still need to implement the read functions, and
then decide whether to return an error or just EOF etc...

> No solution is really satisfactory because right now, our architecture is
> too rigid at this level: protocol -> demuxer -> codecs, and we need a
> different kind of infrastructure at each step of the chain: bistream filters
> for packets between demuxers and codecs, and for now only hacks with slave
> protocols for stream between protocols and demuxers.

I guess I was thinking of something like a protocol filter that
can do transforms (including auto-insertion) on the protocol level
similar to how bitstream filters do it.
But I guess that means we don't have it, and not sure how much effort
it would be to add.
A hack probably shouldn't be that hard, but as it wouldn't be part of
the normal probing it would risk breaking a lot if the auto-detection
isn't 100%...