GNOME Bugzilla – Bug 693484
uridecodebin: query URI to source element and fallback to decoder's URI
Last modified: 2013-04-16 14:55:57 UTC
In the gen_source_element() function various tests are done on the URI used to create the source element. In the case where the source element handles http-like URIs (example webkit+http://...) this breaks on-disk buffering at least because in that case decoder->is_stream is set to FALSE even though the source element is capable of handling on-disk buffering with downstream elements. We should query the URI really used by the source element and fallback to using decoder->uri.
Created attachment 235592 [details] [review] uridecodebin: query URI to source element and fallback to decoder's URI The source element created in gen_source_element() might be able to provide streamable data even though its advertised URI scheme is not in the list of protocols known by uridecodebin to support this feature. To cope with this special case, query the URI to the newly created source element and fallback to the URI already known by the decoder. Fixes bug 693484.
Or maybe do something with the SCHEDULING query here instead, by maybe adding more information to it if there's not enough information in the query yet.
Created attachment 240050 [details] [review] query: new _NEEDS_BUFFERING flag Source elements supporting buffering for downstream elements should set this flag when answering a scheduling query. This is useful for the on-disk buffering scenario of uridecodebin to avoid checking the URI protocol against a list of hardcoded protocols. Bug 693484
Created attachment 240051 [details] [review] uridecodebin: query buffering capability to source element If the source element doesn't handle the query fallback to checking the URI protocol against the hardcoded list of protocols known to handle buffering already. Fixes bug 693484.
Looks good but should probably be implemented in souphttpsrc and others :)
NEEDS_BUFFERING sounds rather specific. I think you want to say that the source is likely going to provide data slower than real-time (in which case you might want to do some buffering).
Ok, some suggestions for the name: BANDWIDTH_LIMITED SPEED_LIMITED MIGHT_BE_SLOW HTTPISH SLOWER_THAN_REALTIME or something along those lines. I currently prefer the first two
Created attachment 240117 [details] [review] query: new _BANDWIDTH_LIMITED flag Source elements with limited bandwidth capabilities and supporting buffering for downstream elements should set this flag when answering a scheduling query. This is useful for the on-disk buffering scenario of uridecodebin to avoid checking the URI protocol against a list of hardcoded protocols. Bug 693484
Created attachment 240118 [details] [review] query: new _BANDWIDTH_LIMITED flag Source elements with limited bandwidth capabilities and supporting buffering for downstream elements should set this flag when answering a scheduling query. This is useful for the on-disk buffering scenario of uridecodebin to avoid checking the URI protocol against a list of hardcoded protocols. Bug 693484
Created attachment 240119 [details] [review] uridecodebin: query buffering capability to source element If the source element doesn't handle the query fallback to checking the URI protocol against the hardcoded list of protocols known to handle buffering already. Fixes bug 693484.
Not that I have any better suggestion, but arguably external USB drives are also bandwidth limited, for example ;)
Created attachment 240121 [details] [review] uridecodebin: query bandwidth capability to source element Use a scheduling query to check if the source element has some bandwidth limitations. If this is the case on-disk buffering might be used. If the source element doesn't handle the scheduling query then fallback to checking the URI protocol against the hardcoded list of protocols known to handle buffering already. Fixes bug 693484.
(In reply to comment #11) > Not that I have any better suggestion, but arguably external USB drives are > also bandwidth limited, for example ;) Strictly speaking everything is bandwidth limited ;) But if you for example play from a very slow drive (floppy disk? :) ) you might want to do buffering too
Review of attachment 240118 [details] [review]: ::: docs/design/part-scheduling.txt @@ +87,3 @@ + downstream element might ask for more data than necessary for + normal playback. This use-case is interesting for on-disk + buffering scenarios for instance. Maybe also add here that you probably don't want to seek as much as on other sources :) ::: win32/common/gstenumtypes.c @@ +1464,3 @@ + {C_FLAGS (GST_SCHEDULING_FLAG_NEEDS_BUFFERING), + "GST_SCHEDULING_FLAG_BANDWIDTH_LIMITED", + "bandwidth-limited"}, This is outdated
Created attachment 240157 [details] [review] query: new _BANDWIDTH_LIMITED flag Source elements with limited bandwidth capabilities and supporting buffering for downstream elements should set this flag when answering a scheduling query. This is useful for the on-disk buffering scenario of uridecodebin to avoid checking the URI protocol against a list of hardcoded protocols. Bug 693484
Created attachment 240194 [details] [review] souphttpsrc: basic scheduling query support Answer to scheduling queries with default parameters and the new _BANDWIDTH_LIMITED_FLAG so that downstream is advised to minimize seek operations and perform on-disk buffering if possible. Bug 693484
commit 54c678a21ec65d5d4aa82ed18116b1ee9624a5e8 Author: Philippe Normand <philn@igalia.com> Date: Fri Mar 29 14:56:57 2013 +0100 query: new _BANDWIDTH_LIMITED flag Source elements with limited bandwidth capabilities and supporting buffering for downstream elements should set this flag when answering a scheduling query. This is useful for the on-disk buffering scenario of uridecodebin to avoid checking the URI protocol against a list of hardcoded protocols. Bug 693484 commit b857cb38ddb63af8ba745c10bece8f1b528af4fe Author: Philippe Normand <philn@igalia.com> Date: Sun Mar 31 12:05:49 2013 +0200 souphttpsrc: basic scheduling query support Answer to scheduling queries with default parameters and the new _BANDWIDTH_LIMITED_FLAG so that downstream is advised to minimize seek operations and perform on-disk buffering if possible. Bug 693484 commit 26fb72cf6577494fed4c00ecba2ad4d746d0caf5 Author: Philippe Normand <philn@igalia.com> Date: Thu Mar 28 14:21:41 2013 +0100 uridecodebin: query bandwidth capability to source element Use a scheduling query to check if the source element has some bandwidth limitations. If this is the case on-disk buffering might be used. If the source element doesn't handle the scheduling query then fallback to checking the URI protocol against the hardcoded list of protocols known to handle buffering already. Fixes bug 693484.