[MSE][GStreamer][seek] During seek, QUOTA_EXCEEDED was thrown, and the seek did not resume

[vertexodessa]

QUOTA_EXCEEDED.txt.gz

[vertexodessa]

Youtube tried to push audio coded chunk of size 3.11MB, but our current default is 3.0 MB, so QUOTA_EXCEEDED exception was thrown.
2017-05-18T12:29:50.646 SourceBuffer::evictCodedFrames(0x4b3f06c0) - currentTime = 539.000000, require 3269402 bytes, maximum buffer size is 3145728

[vertexodessa]

I think we should increase the MSE_MAX_BUFFER_SIZE for audio to 4 MB
@eocanha Enrique what do you think?

[eocanha]

Clearly yes.

[vertexodessa]

should this be a generic change (defaults changed in C++ code), or we should fix by exporting environment variable?

[eocanha]

Please, use the environment variable.

We're dealing with embedded devices and the env. var is the way to fine-tune the sourcebuffer sizes. Take into account that in an ideal world (WebKit upstream[1], assuming desktop) we would have 318 * 0.95 = 302MB for a video sourcebuffer and 318 * 0.05 = 16MB for an audio sourcebuffer. By using the env var we're reducing those values a lot (the devices have little memory) while still trying to keep everything working.

[1]
https://github.com/WebKit/webkit/blob/master/Source/WebCore/page/Settings.in#L238
https://github.com/WebKit/webkit/blob/master/Source/WebCore/html/MediaElementSession.cpp#L628
https://github.com/WebKit/webkit/blob/master/Source/WebCore/html/HTMLMediaElement.cpp#L7047
https://github.com/WebKit/webkit/blob/master/Source/WebCore/Modules/mediasource/SourceBuffer.cpp#L940

[vertexodessa]

@eocanha Enrique, while looking further at the issue with QUOTA EXCEEDED exception, I can see that with the current logging we can not tell for sure, whether it's Youtube pushed a huge buffer, or the exception was thrown since the eviction algorithm failed to evict enough space while appending data during the seek.
actually, I currently think that the latter case happened, i.e. during the seek to a range exactly before the (single) buffered range, appended range might be merged with the currently buffered range, and that led to the situation where eviction algorithm could fail.
I'm verifying this hypothesis and going to look how to improve that if that confirms.

[vertexodessa]

@eocanha hi Enrique.
Let's assume we buffered
[558.599711, 1001.166833) for one of the source buffers. Then, we seek to 537.828966 and append
[537.828966, 558.599711), now the buffered range was merged so we have buffered
[537.828966, 1001.166833). The SourceBuffer is full at this point.
Next, MSE tries to buffer next chunk, it starts with 558.599711 and has some duration. We don't know the duration, but let's assume it's 10 seconds. So the application is now trying to buffer
[558.599711, 568.599711).
This range is already buffered though.
I think there is nothing wrong with re-buffering a range, so the expected behavior should be, to overwrite currently buffered range with the new data.
However, currently the buffer is full and evictCodedFrames will fail to evict the needed amount of bytes, since the only buffered range is the current range, which leads to an early return.
So this will throw QUOTA_EXCEEDED_ERR exception. That's what we're seeing in the log.

However in this case we shouldn't have been throwing the exception, since from the application's point of view it hasn't buffered a lot after the seek.

I'm thinking about ways to solve this problem..

• since we're appending the data to a range that is currently buffered, the proper solution would be to overwrite currently buffered data for this range and ignore the size restrictions for the buffer. However at the time SourceBuffer::appendBufferInternal is called, the data is an unparsed blob, and we don't know where it's going to be appended.

just avoiding early return mentioned above and evicting the data from the end of the buffered range, won't probably work: that might lead to incorrect behavior if an application tries to buffer a lot.

[vertexodessa]

As one of the possible ways to fix this, we can maintain the amount of data appended after the seek and set "buffer full" flag to false, if:

• the only buffered range is the current range
• m_dataAfterSeek is low

[vertexodessa]

@eocanha
I got another idea.
there is a SourceBuffer property m_groupEndTimestamp, that we can try to use to differ data appended after seek,
from data appended in a sequence.
By this I mean that it should be safe to delete buffered data starting from m_groupEndTimestamp in the only buffered range, I am testing this hypothesis.