GNOME Bugzilla – Bug 733921
basesrc: re-negotiate caps in pull mode if necessary
Last modified: 2018-11-03 12:21:51 UTC
This patch solves the case when basesrc is stuck in pull mode and never get the chance to negotiate with downstream (to use a custom memory allocator for example). It happens when typefind is plugged downstream, with the following scenario: filesrc ! typefind ! demuxer (proposing a custom memory allocator). Not sure if the patch is 100% correct though.
Created attachment 281958 [details] [review] basesrc: re-negotiate caps in pull mode if necessary
The issue can be triggered by implementing a fake propose_allocation method to fakesink and the following pipeline: filesrc location=[...] ! typefind ! fakesink The attached patch let filesrc negotiate and call the query allocation.
I don't think basesrc should do anything negotiation/allocator related in this case. Whoever pulls data can pass a buffer to be filled in with data to the source element, so is free to negotiate or use allocators of its choice, allocate a suitably-sized buffer and then pass it to the source to fill with data.
Let say that in the previous pipeline, fakesink provides a custom memory allocator. It is then up to typefind to do the query allocation work, and properly allocate the buffers that will be passed to the source, using gst_pad_pull_range ?
I suppose so. Pull-mode negotiation is not really a very well-defined area, but IMHO the pulling element should do the work. Doing this in typefind would be a bit silly of course, but in a real world example it would be a demuxer and/or parser doing that, which kinda makes sense (to read data directly into decoder-provided buffers, for example). We tried making demuxer do allocation queries at some point, but there were problems and we had to disable it again. It's still something to make work in the long run though. Don't think it will be trivial however, at least not generically with playbin.
-- 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/gstreamer/issues/69.