[Bug 795176] souphttpsrc: Reading in too big blocksizes can cause the connection to time out

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Sat Apr 14 15:12:55 UTC 2018


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

--- Comment #12 from Nicola <lists at svrinformatica.it> ---
(In reply to Sebastian Dröge (slomo) from comment #11)
> Ah nevermind, missed the last comment. Yeah so on the GStreamer side it
> should not just read 0 but also get an GError that the connection was
> closed, or not?


I think the current behaviour is correct here, the server can close the
connection at the end of the file too

> 
> For the solution, I don't really know. Limiting the block-size is an option
> of course, but there's always a trade-off here. Lower block-sizes have lower
> latency and higher overhead, and the opposite for bigger block-sizes.
> 
> A property could make sense, but ideally we could solve this without
> requiring any settings.

probably we should increase block size if bytes_read >= blocksize *
GROW_BLOCKSIZE_LIMIT and the difference in time between the current socket read
and the previous one is <= 1 second or even a smaller value. This way we
increase the block size only if the pipeline is really consuming all these
bytes. 

If the pipeline does not consume the readed bytes quick enough I think that
increasing the blocksize is useless.

If you agree I can work on a patch that implements this but I'm really busy at
the moment and I don't know when I'll have an hour to do this. 

Thanks for your support,

Nicola

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


More information about the gstreamer-bugs mailing list