Initially, GstAudioEncoder calls @start when the encoder element
is activated, which allows subclass to perform any global setup.
GstAudioEncoder calls @set_format to inform subclass of the format
of input audio data that it is about to receive. Subclass should
setup for encoding and configure various base class parameters
appropriately, notably those directing desired input data handling.
While unlikely, it might be called more than once, if changing input
parameters require reconfiguration.
GstAudioEncoder calls @stop at end of all processing.
As of configuration stage, and throughout processing, GstAudioEncoder
maintains various parameters that provide required context,
e.g. describing the format of input audio data.
Conversely, subclass can and should configure these context parameters
to inform base class of its expectation w.r.t. buffer handling.
Just prior to actually pushing a buffer downstream,
it is passed to @pre_push.
During the parsing process GstAudioEncoderClass will handle both
srcpad and sinkpad events. Sink events will be passed to subclass
if @event callback has been provided.
GstAudioEncoder class calls @stop to inform the subclass that data
parsing will be stopped.
Subclass is responsible for providing pad template caps for
source and sink pads. The pads need to be named "sink" and "src". It also
needs to set the fixed caps on srcpad, when the format is ensured. This
is typically when base class calls subclass' @set_format function, though
it might be delayed until calling @gst_audio_encoder_finish_frame.
In summary, above process should have subclass concentrating on
codec data processing while leaving other matters to base class,
such as most notably timestamp handling. While it may exert more control
in this area (see e.g. @pre_push), it is very much not recommended.
In particular, base class will either favor tracking upstream timestamps
(at the possible expense of jitter) or aim to arrange for a perfect stream of
output timestamps, depending on #GstAudioEncoder:perfect-timestamp.
However, in the latter case, the input may not be so perfect or ideal, which
is handled as follows. An input timestamp is compared with the expected
timestamp as dictated by input sample stream and if the deviation is less
than #GstAudioEncoder:tolerance, the deviation is discarded.
Otherwise, it is considered a discontuinity and subsequent output timestamp
is resynced to the new position after performing configured discontinuity
processing. In the non-perfect-timestamp case, an upstream variation
exceeding tolerance only leads to marking DISCONT on subsequent outgoing
(while timestamps are adjusted to upstream regardless of variation).
While DISCONT is also marked in the perfect-timestamp case, this one
optionally (see #GstAudioEncoder:hard-resync)
performs some additional steps, such as clipping of (early) input samples
or draining all currently remaining input data, depending on the direction
of the discontuinity.
If perfect timestamps are arranged, it is also possible to request baseclass
(usually set by subclass) to provide additional buffer metadata (in OFFSET
and OFFSET_END) fields according to granule defined semantics currently
needed by oggmux. Specifically, OFFSET is set to granulepos (= sample count
including buffer) and OFFSET_END to corresponding timestamp (as determined
by same sample count and sample rate).
Things that subclass need to take care of:
Provide pad templates
Set source pad caps when appropriate
Inform base class of buffer processing needs using context's
frame_samples and frame_bytes.
Set user-configurable properties to sane defaults for format and
implementing codec at hand, e.g. those controlling timestamp behaviour
and discontinuity processing.
This base class is for audio encoders turning raw audio samples into encoded audio data.
GstAudioEncoder and subclass should cooperate as follows.
Configuration
As of configuration stage, and throughout processing, GstAudioEncoder maintains various parameters that provide required context, e.g. describing the format of input audio data. Conversely, subclass can and should configure these context parameters to inform base class of its expectation w.r.t. buffer handling.
Data processing
Shutdown phase
Subclass is responsible for providing pad template caps for source and sink pads. The pads need to be named "sink" and "src". It also needs to set the fixed caps on srcpad, when the format is ensured. This is typically when base class calls subclass' @set_format function, though it might be delayed until calling @gst_audio_encoder_finish_frame.
In summary, above process should have subclass concentrating on codec data processing while leaving other matters to base class, such as most notably timestamp handling. While it may exert more control in this area (see e.g. @pre_push), it is very much not recommended.
In particular, base class will either favor tracking upstream timestamps (at the possible expense of jitter) or aim to arrange for a perfect stream of output timestamps, depending on #GstAudioEncoder:perfect-timestamp. However, in the latter case, the input may not be so perfect or ideal, which is handled as follows. An input timestamp is compared with the expected timestamp as dictated by input sample stream and if the deviation is less than #GstAudioEncoder:tolerance, the deviation is discarded. Otherwise, it is considered a discontuinity and subsequent output timestamp is resynced to the new position after performing configured discontinuity processing. In the non-perfect-timestamp case, an upstream variation exceeding tolerance only leads to marking DISCONT on subsequent outgoing (while timestamps are adjusted to upstream regardless of variation). While DISCONT is also marked in the perfect-timestamp case, this one optionally (see #GstAudioEncoder:hard-resync) performs some additional steps, such as clipping of (early) input samples or draining all currently remaining input data, depending on the direction of the discontuinity.
If perfect timestamps are arranged, it is also possible to request baseclass (usually set by subclass) to provide additional buffer metadata (in OFFSET and OFFSET_END) fields according to granule defined semantics currently needed by oggmux. Specifically, OFFSET is set to granulepos (= sample count including buffer) and OFFSET_END to corresponding timestamp (as determined by same sample count and sample rate).
Things that subclass need to take care of: