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

[Nicolas George]

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.

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.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160402/8c15ffa4/attachment.sig>