Problem playing a 1 frame mp3 (encoded as a data: URL or from file)
Submitted by Colin Guthrie
Link to original bug (#729625)
Description
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/4JGDtnf8aS4S7lTmNg5eFTWVS54X2S3EAIwFYv/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
Version: 1.2.2