Especially don't put them into GstStructures in one way or another, just
ignore them or error out cleanly depending on the importance of their
content.
souphttpsrc maintains two variables for the position:
* 'request_position' is where we want to be
* 'read_position' is where we are
During Normal operations both are updated in sync when data arrives. A seek
changes 'request_position' but not 'read_position'.
When the two positions get out of sync, then a new request is send and the
'Range' header is adjusted to the current 'request_position'.
Without this patch, if reading fails, then the source is destroyed. This
triggers a new request, but the range remains unchanged. As a result, the
old range is used and old data will be read.
Changing the 'read_position' to -1 makes it explicitly different from
'request_position' and as a result the 'Range' header is updated correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=773509
At the end of a range request, we don't want to return GST_FLOW_EOS otherwise
the last bytes we just read will be dropped by basesrc.
Instead just return GST_FLOW_OK (which was set just before) and let basesrc
handle the fact we are at the end of the segment.
If we're at the end of a range request, read again to let libsoup
finalize the request. This allows to reuse the connection again later,
otherwise we would have to cancel the message and close the connection.
We have to get rid of the message on EOS when the complete stream is read to
remember that we successfully finished handling this specific message.
Otherwise we will cancel it later and close the connection instead of reusing
it at a later time.
It might also make sense to reuse connections if a non-200 response is
received. As long as there was no connection error, the HTTP connection should
be re-usable.
Update the blocksize depending on how much is obtained from a read
of the input stream. This avoids doing too many reads in small chunks
when larger amounts of data are available and also prevents using
a very large memory area to read a small chunk of data.
https://bugzilla.gnome.org/show_bug.cgi?id=767833
When early returning in gst_soup_http_src_read_buffer() because the
element is FLUSHING, we need to unmap and unref the buffer which was just created.
https://bugzilla.gnome.org/show_bug.cgi?id=766718
Directly setting audio/x-raw caps leads to problems when the delivered
data blocks do not align properly at sample boundaries (for example, a
data block with 391 bytes). So, instead, set audio/x-unaligned-raw to
let a parser be autoplugged.
https://bugzilla.gnome.org/show_bug.cgi?id=689460
Non-blocking read will return the amount of data available without
blocking to wait for the full requested size.
The downside is that now it souphttpsrc needs to have a waiting
mechanism in case there is no data available yet to avoid busy
looping arond the inputstream.
The problem is that the filesrc and souphttpsrc are behaving
differently regarding the calculation of the segment boundaries. The
filesrc is using a non-inclusive boundaries, while the souphttpsrc
uses inclusive. Currently the hlsdemux calculates the boundaries as
inclusive, so for this reason there is no problem with the souphttpsrc,
but there is an issue in the filesrc.
The GstSegment is non-inclusive, so the proposed solution is to use
non-inclusive boundaries in the hlsdemux in order to be consistent.
Make the change in the hlsdemux, will break the souphttpsrc, which
will expect inclusive boundaries, but the hlsdemux will offer
non-inclusive. This change makes sure that the non-inclusive
boundaries are converted to inclusive.
https://bugzilla.gnome.org/show_bug.cgi?id=748316
To allow souphttpsrc to be use HTTP methods other than GET
(e.g. HEAD), add a "method" property that is a string. If this
property is not set, GET is used.
https://bugzilla.gnome.org/show_bug.cgi?id=752413
1) If the system http_proxy environment variable is not set
or set to an empty string, we must not set proxy to avoid
http connection error.
2) In case of proxy property setting, if user want to clear
the proxy setting, they should be able to set it to NULL or
an empty string again, so this is fixed too.
3) Check if the proxy string was parsed correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=752866
basesrc assumes that we don't return a buffer if
something else than OK is returned. It will just
leak any buffer we might accidentially provide
here.
This can potentially happen during flushing.
Maybe fixes https://bugzilla.gnome.org/show_bug.cgi?id=741993
When we cancel connection attempts and similar things, there are still
some operations pending on our main context from the GCancellables. We
should let them all run before unreffing our context, otherwise we leak
file descriptors.
Unfortunately this requires libsoup 2.47.0 or newer as earlier versions
steal our main context from us and we can't use it for cleanup later
without assertions and funny crashes.
Based on a patch by Dmitry Shatrov <shatrov@gmail.com>.
https://bugzilla.gnome.org/show_bug.cgi?id=663944
If nothing happens after 15 seconds, chances are good that
our connection will never will work. Stop after 15 seconds
instead of waiting until the system's default timeout, which
can be > 1 minute.
Only return EOS the next time create() is called, if at all. basesrc
should already take care of not calling it again.
Also always return immediately if the previous flow return was
not OK. This indicates an error somewhere.
Commit 46fd12ae5e introduced connection
recovery. But when server does not specify content-size,
souphttpsrc tries to reconnect even after regular end of stream.
Http server replies with SOUP_STATUS_REQUESTED_RANGE_NOT_SATISFIABLE
but souphttpsrc still emits error instead of EOS.
https://bugzilla.gnome.org/show_bug.cgi?id=724717
Signed-off-by: Branislav Katreniak <bkatreniak@nuvotechnologies.com>
We want to notice ourselves that we're EOS. Otherwise we will
always cancel requests in the very end and confuse the server...
and also make it impossible to use persistent connections.
