After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 703256 - typefind: Fix low probability typefinding for video/mpeg on small amount of data
typefind: Fix low probability typefinding for video/mpeg on small amount of data
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Normal normal
: 1.1.2
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-06-28 14:15 UTC by Vincent Penquerc'h
Modified: 2013-07-01 10:56 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Le patch (2.33 KB, patch)
2013-06-28 14:53 UTC, Vincent Penquerc'h
committed Details | Review

Description Vincent Penquerc'h 2013-06-28 14:15:34 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... :)
Comment 1 Vincent Penquerc'h 2013-06-28 14:53:44 UTC
Created attachment 247992 [details] [review]
Le patch

Attachment creation failed, here we go again.
Comment 2 Sebastian Dröge (slomo) 2013-07-01 09:09:26 UTC
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
Comment 3 Tim-Philipp Müller 2013-07-01 09:32:16 UTC
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)