docs: fix docs

GST_FLOW_WRONG_STATE -> GST_FLOW_FLUSHING

docs/design/part-block.txt

@@ -40,8 +40,8 @@ waiting to be unblocked.
 
 When sending a flushing seek upstream on elem1.src, the FLUSH_START event
 will temporary unblock the streaming thread and make all pad functions that
-triggers a block (_push/_alloc_buffer/_push_event/_pull_range) return
+can trigger a block (_push/_query/_push_event/_pull_range) return
-GST_FLOW_WRONG_STATE. This will then eventually pause the streaming thread
+GST_FLOW_FLUSHING. This will then eventually pause the streaming thread
 and release the STREAM_LOCK. 
 
 Since no STREAM lock is taken after the pad block it is not needed to send

docs/design/part-element-sink.txt

@@ -81,7 +81,7 @@ sink overview
       if (need_commit)
         need_commit = FALSE
         if (!commit)
-          return WRONG_STATE
+          return FLUSHING
 
       if (need_preroll)
         # release PREROLL_LOCK and wait. prerolled can be observed
@@ -90,7 +90,7 @@ sink overview
         PREROLL_WAIT (releasing PREROLL_LOCK)
         prerolled = FALSE
         if (flushing)
-          return WRONG_STATE
+          return FLUSHING
 
     if (valid (start || stop))
       PREROLL_UNLOCK
@@ -98,7 +98,7 @@ sink overview
       ret = wait_clock (obj,start)
       PREROLL_LOCK
       if (flushing)
-        return WRONG_STATE 
+        return FLUSHING 
       # if the clock was unscheduled, we redo the
       # preroll
       if (ret == UNSCHEDULED)
@@ -124,7 +124,7 @@ sink overview
     render (buffer)          ----->|     PREROLL_WAIT (releasing PREROLL_LOCK)
                                    |     prerolled = FALSE
                                    |     if (flushing)
-                                   |       return WRONG_STATE
+                                   |       return FLUSHING
                                    | 
 
   # queue a prerollable item (EOS or buffer). It is
@@ -146,7 +146,7 @@ sink overview
         if (need_commit)
           need_commit = FALSE
           if (!commit)
-            return WRONG_STATE
+            return FLUSHING
 
       # then see if we need more preroll items before we
       # can block
@@ -173,7 +173,7 @@ sink overview
       if (flushing)
         return FALSE
       ret = queue (event, TRUE)
-      if (ret == WRONG_STATE)
+      if (ret == FLUSHING)
         return FALSE
       PREROLL_UNLOCK
       STREAM_UNLOCK
@@ -188,7 +188,7 @@ sink overview
         return FALSE
       set_clip
       ret = queue (event, FALSE)
-      if (ret == WRONG_STATE)
+      if (ret == FLUSHING)
         return FALSE
       PREROLL_UNLOCK
       STREAM_UNLOCK
@@ -225,7 +225,7 @@ sink overview
     STREAM_LOCK
     PREROLL_LOCK
     if (flushing)
-      return WRONG_STATE
+      return FLUSHING
     if (clip)
       queue (buffer, TRUE)
     PREROLL_UNLOCK

docs/design/part-overview.txt

@@ -447,14 +447,14 @@ In the next PAUSED to READY state change the pipeline has to shut down and all
 streaming threads must stop sending data. This happens in the following sequence:
 
  alsasink to READY:   alsasink unblocks from the _chain() function and returns a
-                      WRONG_STATE return value to the peer element. The sinkpad is
+                      FLUSHING return value to the peer element. The sinkpad is
                       deactivated and becomes unusable for sending more data. 
  mp3dec to READY:     the pads are deactivated and the state change completes when
                       mp3dec leaves its _chain() function. 
  filesrc to READY:    the pads are deactivated and the thread is paused.
 
 The upstream elements finish their chain() function because the downstream element
-returned an error code (WRONG_STATE) from the _push() functions. These error codes 
+returned an error code (FLUSHING) from the _push() functions. These error codes 
 are eventually returned to the element that started the streaming thread (filesrc),
 which pauses the thread and completes the state change.
 

docs/design/part-preroll.txt

@@ -47,12 +47,12 @@ The following conditions unlock the preroll:
  - a flush event
 
 When the preroll is unlocked by a flush event, a return value of
-GST_FLOW_WRONG_STATE is to be returned to the peer pad.
+GST_FLOW_FLUSHING is to be returned to the peer pad.
 
 When preroll is unlocked by a state change to PLAYING, playback and
 rendering of the buffers shall start.
 
 When preroll is unlocked by a state change to READY, the buffer is
-to be discarded and a GST_FLOW_WRONG_STATE shall be returned to the
+to be discarded and a GST_FLOW_FLUSHING shall be returned to the
 peer element.
 

docs/design/part-probes.txt

@@ -164,7 +164,7 @@ The push dataflow probe behavior is the same for buffers and bidirectional event
  -------------------->O                               |
                       O                               | 
         flushing?     O                               | 
-        WRONG_STATE   O                               |
+        FLUSHING      O                               |
         < - - - - - - O                               | 
                       O-> do BLOCK probes             | 
                       O                               | 
@@ -176,7 +176,7 @@ The push dataflow probe behavior is the same for buffers and bidirectional event
                       O   gst_pad_send_event()        | 
                       O------------------------------>O
                       O                   flushing?   O 
-                      O                 WRONG_STATE   O 
+                      O                   FLUSHING    O 
                       O< - - - - - - - - - - - - - - -O 
                       O                               O-> do BLOCK probes
                       O                               O 
@@ -217,7 +217,7 @@ If there is a valid DATA item, the DATA probes are called for the item.
                    |                               O<---------------------
                    |                               O
                    |                               O  flushing?
-                   |                               O  WRONG_STATE
+                   |                               O  FLUSHING 
                    |                               O - - - - - - - - - - >
                    |             do BLOCK probes <-O
                    |                               O   no peer?
@@ -227,7 +227,7 @@ If there is a valid DATA item, the DATA probes are called for the item.
                    O<------------------------------O
                    O                               O
                    O flushing?                     O
-                   O WRONG_STATE                   O
+                   O FLUSHING                      O
                    O- - - - - - - - - - - - - - - >O
  do BLOCK probes <-O                               O
                    O                               O

docs/design/part-segments.txt

@@ -40,7 +40,7 @@ Use case: FLUSHING seek
 
     Avidemux starts by sending a FLUSH_START event downstream and upstream. This
     will cause its streaming task to PAUSED because _pad_pull_range() and
-    _pad_push() will return WRONG_STATE. It then waits for the STREAM_LOCK,
+    _pad_push() will return FLUSHING. It then waits for the STREAM_LOCK,
     which will be unlocked when the streaming task pauses. At this point no
     streaming is happening anymore in the pipeline and a FLUSH_STOP is sent
     upstream and downstream.

docs/design/part-states.txt

@@ -77,7 +77,7 @@ the following state changes are possible:
  PAUSED -> READY
    - Sinks unblock any waits in the preroll.
    - Elements unblock any waits on devices
-   - Chain or get_range functions return WRONG_STATE.
+   - Chain or get_range functions return FLUSHING.
    - The element pads are deactivated so that streaming becomes impossible and
      all streaming threads are stopped.
    - The sink forgets all negotiated formats
@@ -195,7 +195,7 @@ The children are iterated from the sink elements to the source elements. This ma
 sure that when changing the state of an element, the downstream elements are in
 the correct state to process the eventual buffers. In the case of a downwards
 state change, the sink elements will shut down first which makes the upstream
-elements shut down as well since the _push() function returns a GST_FLOW_WRONG_STATE
+elements shut down as well since the _push() function returns a GST_FLOW_FLUSHING
 error.
 
 If all the children return SUCCESS, the function returns SUCCESS as well. 

docs/pwg/advanced-events.xml

@@ -241,7 +241,7 @@ gst_my_filter_sink_event (GstPad  *pad, GstEvent * event)
         As a side-effect of flushing all data from the pipeline, this event
         unblocks the streaming thread by making all pads reject data until
         they receive a <xref linkend="section-events-flush-stop"/> signal
-        (elements trying to push data will get a WRONG_STATE flow return
+        (elements trying to push data will get a FLUSHING flow return
          and stop processing data).
       </para>
       <para>

libs/gst/base/gstbasesrc.c

@@ -1455,7 +1455,7 @@ not_ok:
  * When we are in the loop() function, we might be in the middle
  * of pushing a buffer, which might block in a sink. To make sure
  * that the push gets unblocked we push out a FLUSH_START event.
- * Our loop function will get a WRONG_STATE return value from
+ * Our loop function will get a FLUSHING return value from
  * the push and will pause, effectively releasing the STREAM_LOCK.
  *
  * For a non-flushing seek, we pause the task, which might eventually
@@ -1702,7 +1702,7 @@ gst_base_src_send_event (GstElement * element, GstEvent * event)
        *    first and do EOS instead of entering it.
        *  - If we are in the _create function or we did not manage to set the
        *    flag fast enough and we are about to enter the _create function,
-       *    we unlock it so that we exit with WRONG_STATE immediately. We then
+       *    we unlock it so that we exit with FLUSHING immediately. We then
        *    check the EOS flag and do the EOS logic.
        */
       g_atomic_int_set (&src->priv->pending_eos, TRUE);
@@ -2348,10 +2348,10 @@ again:
         gst_buffer_unref (res_buf);
 
       if (!src->live_running) {
-        /* We return WRONG_STATE when we are not running to stop the dataflow also
+        /* We return FLUSHING when we are not running to stop the dataflow also
          * get rid of the produced buffer. */
         GST_DEBUG_OBJECT (src,
-            "clock was unscheduled (%d), returning WRONG_STATE", status);
+            "clock was unscheduled (%d), returning FLUSHING", status);
         ret = GST_FLOW_FLUSHING;
       } else {
         /* If we are running when this happens, we quickly switched between
@@ -2701,7 +2701,7 @@ pause:
       gst_event_set_seqnum (event, src->priv->seqnum);
       /* for fatal errors we post an error message, post the error
        * first so the app knows about the error first.
-       * Also don't do this for WRONG_STATE because it happens
+       * Also don't do this for FLUSHING because it happens
        * due to flushing and posting an error message because of
        * that is the wrong thing to do, e.g. when we're doing
        * a flushing seek. */