From: Stefan Sauer Date: Thu, 25 Sep 2014 19:04:23 +0000 (+0200) Subject: event: 'newsegment' to 'segment' in the docs X-Git-Tag: 1.6.1~736 X-Git-Url: http://review.tizen.org/git/?a=commitdiff_plain;h=7bb838be40761aab878462daad6bc86645198421;p=platform%2Fupstream%2Fgstreamer.git event: 'newsegment' to 'segment' in the docs Brings the api-docs in sync with the 1.0 api rename. --- diff --git a/gst/gstevent.c b/gst/gstevent.c index a1cb381..3cd3522 100644 --- a/gst/gstevent.c +++ b/gst/gstevent.c @@ -715,7 +715,7 @@ gst_event_parse_caps (GstEvent * event, GstCaps ** caps) * downstream synchronized with the buffer flow and contains timing information * and playback properties for the buffers that will follow. * - * The newsegment event marks the range of buffers to be processed. All + * The segment event marks the range of buffers to be processed. All * data not within the segment range is not to be processed. This can be * used intelligently by plugins to apply more efficient methods of skipping * unneeded data. The valid range is expressed with the @start and @stop @@ -736,10 +736,10 @@ gst_event_parse_caps (GstEvent * event, GstCaps ** caps) * stream. (@rate * @applied_rate) should always equal the rate that has been * requested for playback. For example, if an element has an input segment * with intended playback @rate of 2.0 and applied_rate of 1.0, it can adjust - * incoming timestamps and buffer content by half and output a newsegment event + * incoming timestamps and buffer content by half and output a segment event * with @rate of 1.0 and @applied_rate of 2.0 * - * After a newsegment event, the buffer stream time is calculated with: + * After a segment event, the buffer stream time is calculated with: * * time + (TIMESTAMP(buf) - start) * ABS (rate * applied_rate) *