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 796933 - avfassetsrc: deadlock on processing (flushing) seek event
avfassetsrc: deadlock on processing (flushing) seek event
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
1.14.x
Other Mac OS
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2018-08-08 10:27 UTC by Stephan Hesse
Modified: 2018-11-03 14:29 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Stephan Hesse 2018-08-08 10:27:35 UTC
Running on XCode Simulator any iDevice model with iOS v11.4 as well as real devices (for example iPhone 7 with v11.4.1):

Reproduce:

When playing a local MP3 or MP4 file via playbin, and filesrc factory-rank is downgraded against avfassetsrc (like it is done in the current gst-examples iOS playback project) performing any flushing seek will cause a deadlock to happen.

When processing the seek event, we are waiting somewhere after `avfassetsrc.m:726:gst_avf_asset_src_stop_reading` 

...but I haven't investigated the exact cause yet. Someone who has touched this code before has an idea here?

See logs here: https://gist.github.com/tchakabam/0b277e1947ba51395399206725049171

A local file URL can be bundled in the project `Resources` folder and passed to the player conveniently like so:

```
    NSString *localFile = @"guitars.m4a";
    
    NSURL *localURL = [[NSBundle mainBundle] URLForResource: localFile withExtension:nil];
    
   g_object_set (player, "uri", [localURL.absoluteString UTF8String], NULL);
```

... just adding that snippet, because the current gst-examples code doesn't include any local files for testing (only the deprecated media library stuff).

We suspect this issue might be result of Apple-side API implementation having evolved since previous versions when this plugin was made and that it used to work back then. Could that be possible?

Our current workaround is to use the filesrc instead to access local media, which results in a decodebin/atdec based pipeline, which as expected works fine.

Some more questions:

We were also wondering what the advantages are to use a monolithic approach to reading/decoding as it is done with avfassetsrc compared to filesrc/decodebin based pipeline? We suspect performance is more optimal when using the native system component to do the whole job, but is it really noticeable? When playing HLS via adaptivedemux for example we don't seem having to worry about that, and it is using the same pipeline downstream, while it's more logic in adaptivedemux than what happens in filesrc I would guess. Or is there such a large overhead in accessing files with filesrc compared to AVAssetReader? Should we worry about using the filesrc mode and actively try to fix this so our app can use avfassetsrc instead?
Comment 1 GStreamer system administrator 2018-11-03 14:29:28 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/766.