Trying to diagnose a READY --> PAUSED transition bug

Thibault Saunier tsaunier at gnome.org
Tue Mar 26 13:02:48 UTC 2019


Hey,

Looking at the diagram, it looks like the muxer is never outputing any
buffer and is not negotiating its output, you should check how buffer are
flowing in the debug log, also a stack trace could be useful.

BR,

Thibault

On Tue, Mar 26, 2019 at 8:08 AM Thornton, Keith <keith.thornton at zeiss.com>
wrote:

> Hi,
>
> Can filesink accept a segment in time format, I would have thought in
> needs a byte format segment message
>
>
>
> *Von:* gstreamer-devel <gstreamer-devel-bounces at lists.freedesktop.org> *Im
> Auftrag von *David Ing
> *Gesendet:* Montag, 25. März 2019 22:20
> *An:* Discussion of the development of and with GStreamer <
> gstreamer-devel at lists.freedesktop.org>
> *Betreff:* Trying to diagnose a READY --> PAUSED transition bug
>
>
>
> I am using Gstreamer 1.14.4.  I am having an issue with one of my
> pipelines on Windows.  I attached an SVG file which shows my pipeline at
> the point in time when it gets stuck.  The issue occurs when I try to move
> my pipeline from READY to PAUSED.  I do this by calling
> gst_element_set_state(gstPipeline, GST_STATE_PAUSED), and after that call
> is made, I see all elements within the pipeline transition to PAUSED except
> the *GstFileSink which remains stuck in READY*.
>
>
>
> Also:
>
>    - The issue does not repro on Linux (only Windows).
>    - I use the same basic code to render many other kinds of jobs and I
>    never have a problem with the GstFileSink.  It is only for this one
>    specific pipeline that I have the problem.
>    - I am 100% certain that this isn't some kind of file system issue
>    (e.g. folder permissions).
>
> For logging I set the the "filesink" category to TRACE and this is the
> entirety of what it shows me:
>
>
>
> Pipeline is in NULL state, as I connect the muxer to the filesink I see
> this:
>
>
>
> 19-03-25T20:44:19.420327 INFO    filesink gstfilesink.c:294 filename :
> C:\dev\github\panopto\panopto-core\Debug\x64\test-scratch\2019-03-25T20-44-11.942351\CompositionTests\Debug\0ed40ba8-7d3d-4569-8294-aa02017efdfc-9531e8a6-d94f-44ed-a79a-aa0b0008a713.mp4
>
> 19-03-25T20:44:19.420327 INFO    filesink gstfilesink.c:295 uri      :
> file:///C:/dev/github/panopto/panopto-core/Debug/x64/test-scratch/2019-03-25T20-44-11.942351/CompositionTests/Debug/0ed40ba8-7d3d-4569-8294-aa02017efdfc-9531e8a6-d94f-44ed-a79a-aa0b0008a713.mp4
>
>
>
> Immediately after I call  gst_element_set_state(gstPipeline,
> GST_STATE_READY)  , I see:
>
>
>
> 19-03-25T20:44:19.458327 DEBUG   filesink gstfilesink.c:516 Seeking to
> offset 0 using fseeko
>
> 19-03-25T20:44:19.458327 DEBUG   filesink gstfilesink.c:416 opened file
> C:\dev\github\panopto\panopto-core\Debug\x64\test-scratch\2019-03-25T20-44-11.942351\CompositionTests\Debug\0ed40ba8-7d3d-4569-8294-aa02017efdfc-9531e8a6-d94f-44ed-a79a-aa0b0008a713.mp4,
> seekable 1
>
>
>
> 6.3 seconds after I call  gst_element_set_state(gstPipeline,
> GST_STATE_PAUSED)  , I see:
>
>
>
> 19-03-25T20:44:25.853308 DEBUG   filesink gstfilesink.c:586 Ignored
> SEGMENT event of format 3 (time)
>
>
>
> My best guess is that it's some kind of rare timing bug within gstreamer
> (which most pipelines are lucky to avoid).
>
>
>
> I am looking for tips about how to diagnose the exact cause of this bug:
> But keep in mind that I have no debug symbols because I'm on Windows.
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20190326/75eac379/attachment.html>


More information about the gstreamer-devel mailing list