GNOME Bugzilla – Bug 794505
souphttpsrc: Eos is not emitted for not satisfiable range seek
Last modified: 2018-11-03 15:27:24 UTC
When seeking to not satisfiable range (for example, out of the content length), eos is not emitted but error occurs after applying the patch below. 2014-02-13 12:09 Sebastian Dröge o │ souphttpsrc: Use new automatic_eos API from basesrc Likewise previous version, error should not emitted but eos is expected if the player try to seek to content length.
Created attachment 369883 [details] [review] souphttpsrc: Set automatic_eos default to TRUE When seeking to not satisfiable range (for example, out of the content length), eos is not emitted but error occurs if automatic_eos is FALSE. Likewise previous version, error should not emitted but eos is expected if the player try to seek to content length.
Can you provide some kind of testcase for this?
I think this can be used as testcase 1. Play any file 2. Seek to out of the duration of the file.
More specifically, we expect the following line if seek to bigger than content_size is performed, but if we set automatic_eos FALSE, EOS does not occur immediately. if (src->have_size && segment->start >= src->content_size) { GST_WARNING_OBJECT (src, "Potentially seeking behind end of file, might EOS immediately"); }
Comment on attachment 369883 [details] [review] souphttpsrc: Set automatic_eos default to TRUE The automatic EOS setting of basesrc was specifically added for souphttpsrc. Check the GIT commits in souphttpsrc and basesrc that added this. The problem is that for HTTP we don't know when we're done but we have to wait until the server is done sending us data. If we stop at the duration, we might produce too little data.
What do you think below? If we do not stop at the request of the duration, server may send 416 error response if automatic eos and we may not wait until server is done sending us data. http://httpwg.org/specs/rfc7233.html If all of the preconditions are true, the server supports the Range header field for the target resource, and the specified range(s) are invalid or unsatisfiable, the server SHOULD send a 416 (Range Not Satisfiable) response.
This is not about seeking per-se but generally that the Content-Range header might be incomplete. Consider a file that is currently still growing server-side, or also when using compression I remember the Content-Range to be smaller than the amount of bytes that actually arrived in the end (and basesrc would then EOS before the end).
I'm seeing this issue in combination with queue2. When queue2 switches back to range that contains the end of the file, it will seek with start=content_size, stop=-1. Btw, there is code already that turns the error into EOS, but only if the content size is not known
Created attachment 371127 [details] [review] souphttpsrc: don't fail when seeking past the end of the content Range errors are already turned into EOS when the size is not known. Do the same thing if the request as outside the known content size.
-- 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-good/issues/452.