mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-12-24 09:10:36 +00:00
95f6e0dbe4
Consider a downstream element that may issue seeks in very short succession (e.g. queue2), depending on the access pattern of the downstream element (e.g. qtdemux with audio/video chunks interleaved so that there's always a sizeable gap between the current chunks for each stream). In this case, queue2 will maintain two ranges, and even when it serves a chunk from memory, it will switch ranges and make souphttpsrc seek to the end of the available data for that range, assuming that that's where we'll want to continue reading from next. This may lead to the following seek request pattern: - source reading position A - seek to B - now reading position still A, requested_postion is B - streaming thread to be restarted to continue from B - seek to A, before streaming thread had time to do the seek - do_seek() now sees reading position == seek position and returns early. - however, requested position is still B from the earlier seek request - streaming thread starts up, sees that a seek to B is pending and requests data from B from the server, while the GstBaseSrc segment has of course been updated/reset to position A, which was the last seek request. - we will now send data for position B and pretend that's the data from position A (via the newsegment event, etc.) - this causes data corruption Reproducible doing seek-emulated fast-forward/backward on 006648. |
||
|---|---|---|
| .. | ||
| gstsoup.c | ||
| gstsouphttpclientsink.c | ||
| gstsouphttpclientsink.h | ||
| gstsouphttpsrc.c | ||
| gstsouphttpsrc.h | ||
| Makefile.am | ||