[Bug 729625] New: Problem playing a 1 frame mp3 (encoded as a data: URL or from file)

Tue May 6 01:22:24 PDT 2014

https://bugzilla.gnome.org/show_bug.cgi?id=729625
  GStreamer | gstreamer (core) | 1.2.2

           Summary: Problem playing a 1 frame mp3 (encoded as a data: URL
                    or from file)
    Classification: Platform
           Product: GStreamer
           Version: 1.2.2
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gstreamer (core)
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: colin at mageia.org
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

I believe (from speaking to Sebastian) that this is actually two bugs, but I'll
explain below.

Background: The nuvolaplayer (https://nuvolaplayer.fenryxo.cz) uses GStreamer
to provide HTML5 support for Google Music. This avoids the need for using the
Flash plugin to play the audio content, and we'd all like to see less use of
Flash I'm sure!

The problem comes when the Google side does a test to see if the HTML5 support
is functional. It does this by playing a silent, one-frame mp3 encoded as a
data: url in base64. With GStreamer, this fails and thus HTML5 support is not
enabled and Google Music thus falls back to Flash (ugg).

Here is a test pipleline:

gst-launch-1.0 playbin
uri="data:audio/mpeg;base64,//vgZAAACZ2B1FVl4ACUEFrIoJgAagonULndgAK2RKx7FtAAAAC4AABKIwQSyZbdAOkWy+AgQUbTx98nvic7ZnhsfTkLYFxFcD/Q801XIhhoE4NAnZO0eTAOAA0AFARhOg2AVAuBoIYrFYyPL+jx5ElP8nYmgagHIEgEMLgyUgP37Gr0PQ80y3k7HoHoHoIQTg6FAyRLsZzlvJ2TsuZpqNDEMUCsZHkSkNWQS/i3ibi5mW+OQesXMhZczTQ9D1e/iU1ljT6jfEoBzhIyXu2BDEMQxDDTOtD0PV6vfx8J9R2PwWwHIDkFgcS2EILgaBoHQhiseR77gKw5DQUEFgVjJEyxoeW8uY9A9BCCcE4JwXA0DoOtD0PQ85zTJ2XM61ArFYyPKe7948pSlKfNNXhv7+A8V6vV6vV6vV6fUaGIYhiGIYrEMQxDDTNM0zrQ9D1ezv3jx48eRKAGAAAAxjGMb3AAAFHEREREZv//92QIRH/////92QjO99ou7u7smmQIEIiIMIAMBhZMmTu7iIiIiIu73xERd3e////xEZ4iIiP/////+0RH////e7uIiIiIi7JkyZMmTuIiIiP4//7QQAYDJkyZMmTJkCBAghERBNO98REXd3d3dxEGECCGOQQiIiCBAmTJkyZMmns4AwAIABg6IximJldpt0cA4xxL4z2OorDYw8rYFBiZEuAGTMYJAaYXiIkqapA4CgXMBEjCwKrh/tPQaMVJN/M/ugNtwzOgZQZnRnnEZ2A/5mPGBnTvtxLcmFDYFbjVgv88QauGkjf3fMBCg1nQ8QmlpU6aBNt/tf+4KSb//m09DIgQyQHfQuclSg6oKIHoBKbrc1/mEoAtPUfP/5aZofFmqthwn1dkQCFYzM5v///ocLKplR9j//uYFSAyUKQ2fqtTRqYCosHFta2CiCK9//jIFGygZ/yaEkPf/4JGDtnf8aS4S7lTmN
 g5eFTWVS54X2S3EAIwFYv/pPQx4C5///XBGkCV//+lWYyC5f//mjoHFNXrXcqGDR0HRySGaSxGBePSletpQIustFFVCT///////3cFqEwXh//+hIUbH///////////yYYFFrb///IWEnK6AAAAABAAAAAAChLqAAkbf5sLM9YLgmjtHGW4DOAB96S2/F4xpBxGWHCY6JiXUxMOYCjxcHqPYxLprt6vw2Aph7DiJEeo9SWE6+FGXG9YBvHq0VGQW+C2t6y7CdN8Ygna0dahPzBE1Ft9YmqeS35IEPRU5mNJeJIxHqPUyNw4przUT5/kV282GFf5FHo9SKKI7BuSzJFEQ5ID2HsYl01//YXDb6x8Pf//mxA/JEopiCmopmXHJyXGoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=="

It produces:

Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
ERROR: from element
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind:
Could not determine type of stream.
Additional debug info:
gsttypefindelement.c(1067): gst_type_find_element_loop ():
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
Freeing pipeline ...

Enabling debugging I can make a few observations:

The dataurisrc seems to correctly extract the mime type from the URL and
properly decode the payload. Good start.

When the type find system kicks in, it does not see that some caps are set and
still tries to determine the type of the stream by parsing an extension out of
the URL. With data: URLs this is really not a nice idea.

I tried a hideous hack >:) to make dataurisrc "fake" the URL provided to the
rest of the system (i.e. I replaced it with "file:///fake-uri.mp3"). This
allowed things to get further, but type find still failed to detect the type of
the stream. I presume this is because it was simply too short.

To confirm this last theory, I took the base64 data, passed it through base64
-d and piped it to a file mp3.mp3 and tried a simple playbin pipeline, avoiding
the dataurisrc completely. It still failed with the same error as above:

gst-launch-1.0 playbin uri=file://`pwd`/mp3.mp3 
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
ERROR: from element
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind:
Could not determine type of stream.
Additional debug info:
gsttypefindelement.c(1067): gst_type_find_element_loop ():
/GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstTypeFindElement:typefind
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
Freeing pipeline ...

However, specifying the pipeline manually (to avoid typefind) works fine:

gst-launch-1.0 filesrc location=mp3.mp3 ! mpeg2dec ! autoaudiosink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Got EOS from element "pipeline0".
Execution ended after 0:00:00.000087481
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...

For reference, vlc (I think), mplayer and mpg123 play the file fine, although
mpg123 does print out an amusing:

[parse.c:1007] warning: Cannot read next header, a one-frame stream? Duh...

:)

I spoke privately to Sebastian about this before reporting the bug. I had hoped
that it was just that the dataurisrc's caps were not being trusted by the core
when in pull mode and thus the typefind kicked in, but he corrected me saying
that the mime type was not sufficient on it's own anyway. The fact that I could
make it fail without the dataurisrc makes me confident he's correct, but I'm
fairly certainly that you would want to avoid trying to extract a file
extension from a data: uri anyway (hence why I think this is actually two
bugs).

This was reported a long time ago in Launchpad for Ubuntu but I see no progress
and no actual upstream report which is pretty weird (why did no one report this
upstream yet? That said, I did find a potential duplicate... from 2006, but Tim
says it's fixed ;) bug #153004 this fix may have been lost over the years I
guess)

Anyway, Launchpad bug:
https://bugs.launchpad.net/ubuntu/+source/gstreamer1.0/+bug/1204672

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.