[Bug 796933] New: avfassetsrc: deadlock on processing (flushing) seek event

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=796933

            Bug ID: 796933
           Summary: avfassetsrc: deadlock on processing (flushing) seek
                    event
    Classification: Platform
           Product: GStreamer
           Version: 1.14.x
                OS: Mac OS
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-bad
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: tchakabam at gmail.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

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?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.