Parse


Object Hierarchy:

Object hierarchy for Parse

Description:

[ CCode ( type_id = "gst_base_parse_get_type ()" ) ]
[ GIR ( name = "BaseParse" ) ]
public abstract class Parse : Element

This base class is for parser elements that process data and splits it into separate audio/video/whatever frames.

It provides for:

* provides one sink pad and one source pad * handles state changes * can operate in pull mode or push mode * handles seeking in both modes * handles events (SEGMENT/EOS/FLUSH) * handles queries (POSITION/DURATION/SEEKING/FORMAT/CONVERT) * handles flushing

The purpose of this base class is to provide the basic functionality of a parser and share a lot of rather complex code.

typeof (unichar2) Description of the parsing mechanism:

typeof (unichar2) typeof (unichar2) Set-up phase

* Parse calls start to inform subclass that data processing is about to start now.

* Parse class calls set_sink_caps to inform the subclass about incoming sinkpad caps. Subclass could already set the srcpad caps accordingly, but this might be delayed until calling finish_frame with a non-queued frame.

* At least at this point subclass needs to tell the Parse class how big data chunks it wants to receive (minimum frame size ). It can do this with set_min_frame_size.

* Parse class sets up appropriate data passing mode (pull/push) and starts to process the data.

typeof (unichar2) typeof (unichar2) Parsing phase

* Parse gathers at least min_frame_size bytes of data either by pulling it from upstream or collecting buffers in an internal Adapter.

* A buffer of (at least) min_frame_size bytes is passed to subclass with handle_frame. Subclass checks the contents and can optionally return OK along with an amount of data to be skipped to find a valid frame (which will result in a subsequent DISCONT). If, otherwise, the buffer does not hold a complete frame, handle_frame can merely return and will be called again when additional data is available. In push mode this amounts to an additional input buffer (thus minimal additional latency), in pull mode this amounts to some arbitrary reasonable buffer size increase.

Of course, set_min_frame_size could also be used if a very specific known amount of additional data is required. If, however, the buffer holds a complete valid frame, it can pass the size of this frame to finish_frame.

If acting as a converter, it can also merely indicate consumed input data while simultaneously providing custom output data. Note that baseclass performs some processing (such as tracking overall consumed data rate versus duration) for each finished frame, but other state is only updated upon each call to handle_frame (such as tracking upstream input timestamp).

Subclass is also responsible for setting the buffer metadata (e.g. buffer timestamp and duration, or keyframe if applicable). (although the latter can also be done by Parse if it is appropriately configured, see below). Frame is provided with timestamp derived from upstream (as much as generally possible), duration obtained from configuration (see below), and offset if meaningful (in pull mode).

Note that handle_frame might receive any small amount of input data when leftover data is being drained (e.g. at EOS).

* As part of finish frame processing, just prior to actually pushing the buffer in question, it is passed to pre_push_frame which gives subclass yet one last chance to examine buffer metadata, or to send some custom (tag) events, or to perform custom (segment) filtering.

* During the parsing process Parse will handle both srcpad and sinkpad events. They will be passed to subclass if sink_event or src_event implementations have been provided.

typeof (unichar2) typeof (unichar2) Shutdown phase

* Parse 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 (e.g. when base class calls subclass' set_sink_caps function).

This base class uses DEFAULT as a meaning of frames. So, subclass conversion routine needs to know that conversion from TIME to DEFAULT must return the frame number that can be found from the given byte position.

Parse uses subclasses conversion methods also for seeking (or otherwise uses its own default one, see also below).

Subclass start and stop functions will be called to inform the beginning and end of data processing.

Things that subclass need to take care of:

* Provide pad templates * Fixate the source pad caps when appropriate * Inform base class how big data chunks should be retrieved. This is done with set_min_frame_size function. * Examine data chunks passed to subclass with handle_frame and pass proper frame(s) to finish_frame, and setting src pad caps and timestamps on frame. * Provide conversion functions * Update the duration information with set_duration * Optionally passthrough using set_passthrough * Configure various baseparse parameters using set_average_bitrate, set_syncable and set_frame_rate.

* In particular, if subclass is unable to determine a duration, but parsing (or specs) yields a frames per seconds rate, then this can be provided to Parse to enable it to cater for buffer time metadata (which will be taken from upstream as much as possible). Internally keeping track of frame durations and respective sizes that have been pushed provides Parse with an estimated bitrate. A default convert (used if not overridden) will then use these rates to perform obvious conversions. These rates are also used to update (estimated) duration at regular frame intervals.


Namespace: Gst.Base

Content:

Properties:

Creation methods:

Methods:

Fields:

Inherited Members:

All known members inherited from class Gst.Element