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 722801 - GstAppSrc fails to open files when type is RANDOM_ACCESS
GstAppSrc fails to open files when type is RANDOM_ACCESS
Status: RESOLVED NOTABUG
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
0.10.36
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-01-22 22:38 UTC by Daniel Nicoletti
Modified: 2014-01-27 13:29 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Test application (7.63 KB, text/x-csrc)
2014-01-22 22:38 UTC, Daniel Nicoletti
Details

Description Daniel Nicoletti 2014-01-22 22:38:15 UTC
Created attachment 267005 [details]
Test application

Hi,

I'm using gstreamer through QtMultimedia 5, and I feed Gstreamer with AppSrc because my files although local are encrypted.

When I started the application I simply passed the file URL as it wasn't encrypted yet, and so far all files were working, then when I started using AppSrc some formats stopped working, after some digging I found out that making Qt set GST_APP_STREAM_TYPE_STREAM instead of GST_APP_STREAM_TYPE_RANDOM_ACCESS on some mp3 made them play fine. It was a ok workaround till last week when I started testing with the 500GB of all sorts of files (it's an app for Jukebox machines). Then even with GST_APP_STREAM_TYPE_STREAM lots of videos didn't play well, so far I had even reported a bug in Qt about it but they were unable to reproduce it.

I talked with some of you at IRC and __Tim suggested me to send a test app, so I went on digging a simple app that didn't use Qt to try to see if Qt guys had done something wrong, I found these:
https://source.ridgerun.net/svn/leopardboarddm365/sdk/trunk/fs/apps/gst-plugins-base-0.10.23/src/tests/examples/app/

And just found out that these simple examples had the same issues as my Qt application, and I also found out that GST_APP_STREAM_TYPE_SEEKABLE is the type that plays now close to 100% of the files, but that doesn't make much sense according to the description as GST_APP_STREAM_TYPE_SEEKABLE vs GST_APP_STREAM_TYPE_RANDOM_ACCESS seems to be more about deliver speed than supporting formats.

I'm attaching a modified version that I played with (to make it look more like the Qt source code) that fails to play this file for example:
http://goo.gl/WODLFF 

Thanks
Comment 1 Daniel Nicoletti 2014-01-22 22:39:43 UTC
Ah and sorry I think the title is misleading since AppSrc doesn't open the files, it substituting open with decode is probably more accurate ;)
Comment 2 Tim-Philipp Müller 2014-01-25 12:53:16 UTC
Can this be closed?

I believe we tracked down the issue to EOS handling and short buffers in the code using appsrc?
Comment 3 Daniel Nicoletti 2014-01-27 13:29:08 UTC
Yes,
I've successfully patched Qt and the suggestions to properly emit an End Of Stream worked correctly, I'm now trying to send the patch upstream.

Thanks.