mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-06-17 05:20:37 +00:00
2c86c99241
Original commit message from CVS: * MAINTAINERS: Update with new email address. * docs/design/part-TODO.txt: Add some more info about future pad-block and negotiation changes. * docs/design/part-buffering.txt: Add some ideas about buffering reporting.
80 lines
2.6 KiB
Plaintext
80 lines
2.6 KiB
Plaintext
Buffering
|
|
---------
|
|
|
|
This document outlines the buffering policy used in the GStreamer
|
|
core that can be used by plugins and applications.
|
|
|
|
The purpose of buffering is to accumulate enough data in a pipeline so that
|
|
playback can occur smoothly and without interruptions. It is typically done
|
|
when reading from a (slow) and non-live network source.
|
|
|
|
Some use cases:
|
|
|
|
+---------+ +--------+ +-------+
|
|
| httpsrc | | buffer | | demux |
|
|
| src - sink src - sink ....
|
|
+---------+ +--------+ +-------+
|
|
|
|
In this case we are reading from a slow network source into a buffer element
|
|
(such as queue).
|
|
|
|
The buffer element has a low and high watermark expressed in bytes. The
|
|
buffer uses the watermarks as follows:
|
|
|
|
- The buffer element will not produce data on the src pad until the high
|
|
watermark is hit. While accumulating data in the buffer, progress is
|
|
reported by posting BUFFERING messages.
|
|
- The source will stop to produce data on the src pad when the low watermark
|
|
is hit.
|
|
|
|
|
|
Messages
|
|
--------
|
|
|
|
A GST_MESSAGE_BUFFERING must be posted on the bus when playback temporarily
|
|
stops to buffer and when buffering finishes. When percentage field in the
|
|
BUFFERING message is 100, buffering is done. Values less than 100 mean that
|
|
buffering is in progress.
|
|
|
|
The BUFFERING message should be intercepted and acted upon by the application.
|
|
|
|
|
|
Application
|
|
-----------
|
|
|
|
While data is buffered, the pipeline should remain in the PAUSED state. It is
|
|
also possible that more data should be buffered while the pipeline is PLAYING,
|
|
in which case the pipeline should be PAUSED until the buffering finished.
|
|
|
|
BUFFERING messages can be posted while the pipeline is prerolling. The
|
|
application should not set the pipeline to PLAYING before a BUFFERING message
|
|
with 100 percent value is received, which might only happen after the pipeline
|
|
prerolled.
|
|
|
|
|
|
Buffering Query
|
|
---------------
|
|
|
|
It is possible to query the amount of buffering performed in the pipeline, which
|
|
is defined as the amount of data made available at the source. This amount is
|
|
expressed in some GstFormat and is usually compared to the duration or position
|
|
of the media stream in the same GstFormat.
|
|
|
|
The buffering query should return the following information:
|
|
|
|
- format
|
|
- position
|
|
- duration
|
|
|
|
The format is of lesser importance, the ratio of position versus duration can be
|
|
used to calculate the percentage of available media. It should also be possible
|
|
for the application to calculate the expected time when the complete file will
|
|
be buffered.
|
|
|
|
|
|
|
|
Incremental download
|
|
--------------------
|
|
|
|
|