GNOME Bugzilla – Bug 796933
avfassetsrc: deadlock on processing (flushing) seek event
Last modified: 2018-11-03 14:29:28 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?
-- 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.