[Bug 702282] New: gstbasesink makes element go to PLAYING without PAUSED_TO_PLAYING transition

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=702282
  GStreamer | gstreamer (core) | git

           Summary: gstbasesink makes element go to PLAYING without
                    PAUSED_TO_PLAYING transition
    Classification: Platform
           Product: GStreamer
           Version: git
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: blocker
          Priority: Normal
         Component: gstreamer (core)
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: youness.alaoui at collabora.co.uk
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


Created an attachment (id=246846)
 --> (https://bugzilla.gnome.org/attachment.cgi?id=246846)
Test code to reproduce basesink bug

It looks like basesink is somehow making the element go to PLAYING state but it
doesn't go through the PAUSED state.. or at least, it doesn't get the
PAUSED_TO_PLAYING transition which makes pulsesink not work.

In my code, using autoaudiosink, it's working (uses pulsesink internally), but
if I replace it with pulsesink directly, it stops working... 
The difference I noticed in the log is that with autoaudiosink, it says
"commiting state to PAUSED" then the whole preroll, etc.. while with pulsesink
it directly says "commiting state to PLAYING".

The actual issue with the sound is that it doesn't do the latency query, so
when it does a get_calibration on PulseSinkClock, it gets 'cexternal = 0' which
makes it wait days before rendering the first buffer, while the one with
autoaudiosink does do the latency query, and sets calibration on the clock (in
sync_latency) which makes audiobasesink report the right buffer timestamps
because PulseSinkClock doesn't return a wrong external calibration value

in audiobasesink, on the state change PAUSED_TO_PLAYING, it does this :
      GST_DEBUG_OBJECT (sink, "ringbuffer may start now");
      sink->priv->sync_latency = TRUE;
In my log, when using pulsesink directly, there isn't any "ringbuffer may start
now", that's why it doesn't call sync_latency when the first buffer arrives and
why the PulseSinkClock is not calibrated and reports wrong values, and I
believe that issue is caused by the missing PAUSED_TO_PLAYING transition.
If I force the sink to go to PAUSED before going to PLAYING, then it works.

I wrote a small test code to reproduce this bug, and I've attached it to this
bug report.
You will see I set my pipeline to playing, then I add the source and sink to it
and set them to PLAYING. When you run it, no sound will play and the g_debug
will output that the sink is in the state PLAYING.
If you enable GST_DEBUG=audiobasesink:5, you will notice that the debug message
"ringbuffer may start now" does not appear, even though the element went to the
PLAYING state.
If you uncomment the line that uses autoaudiosink, it works and on stdout, it
will report that the state of the sink is PAUSED, and the "ringbuffer may start
now" message does appear.
If you use the alternative code that sets the element to PAUSED first, it will
work with pulsesink.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.