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
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel