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