GNOME Bugzilla – Bug 703256
typefind: Fix low probability typefinding for video/mpeg on small amount of data
Last modified: 2013-07-01 10:56:47 UTC
With the current test, we get into problems when we try to typefind a MPEG stream from a small amount of data, which can happen when we get data pushed from a HTTP source. We thus make a second test to give higher probability if all the potential headers were either pack or pes headers (ie, no potential header was unrecognized). This fixes an issue with a MPEG1/MP2 stream being properly discovered as video/mpeg from a file, but as audio/mpeg from souphttpsrc. I'm not overlay certain this won't in turn make something typefind as mpeg/ts while it is presently typefound as something else (correctly) though. Typedinding probabilities are such a dark art... :)
Created attachment 247992 [details] [review] Le patch Attachment creation failed, here we go again.
commit 5a064ca4234ecbc9451b59d36b4e4f13de203d4f Author: Vincent Penquerc'h <vincent.penquerch@collabora.co.uk> Date: Fri Jun 28 14:48:19 2013 +0100 typefind: avoid too low mpeg/ts probability on small amount of data With the current test, we get into problems when we try to typefind a MPEG stream from a small amount of data, which can happen when we get data pushed from a HTTP source. We thus make a second test to give higher probability if all the potential headers were either pack or pes headers (ie, no potential header was unrecognized). This fixes an issue with a MPEG1/MP2 stream being properly discovered as video/mpeg from a file, but as audio/mpeg from souphttpsrc. https://bugzilla.gnome.org/show_bug.cgi?id=703256
Makes sense. Though taking a step back, we really need a way for the typefinder to say that it wants more data (and how much more) before making a decision, or for making a better decision. (I have vague plans to redo the whole typefinding system a little bit in the far future, this is one of those things)