Error using sync=true on a sink

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Error using sync=true on a sink

gimmeamilk
I'm experimenting with playback rate control and am doing some testing just using a fake sink:

pipeline = gst_parse_launch ("filesrc location=myfile.mp4 ! qtdemux name=demux demux.video_0 ! h264parse ! mpegtsmux ! progressreport update-freq=1 ! fakesink sync=true", NULL);
gst_element_set_state (pipeline, GST_STATE_PLAYING);
sleep(3);
printf ("sending seek event now\r\n");
gst_element_seek (pipeline, 2.0, GST_FORMAT_TIME, GST_SEEK_FLAG_FLUSH, GST_SEEK_TYPE_SET, 60 * GST_SECOND, GST_SEEK_TYPE_NONE, 0);


The progress report implies that the playback position and rate change to what I expect after 3s, but I also get the message

ERROR: from element /GstPipeline:pipeline0/GstFakeSink:fakesink0: Internal data flow problem.
Additional debug info:
gstbasesink.c(3225): gst_base_sink_chain_unlocked (): /GstPipeline:pipeline0/GstFakeSink:fakesink0:
Received buffer without a new-segment. Assuming timestamps start from 0.

I don't get this if I set sync=false on the fakesink, but then of course it is not rate-controlled. Is there something else I should be doing to allow sync=true or equivalent on a sink? Thanks.
Reply | Threaded
Open this post in threaded view
|

Re: Error using sync=true on a sink

gimmeamilk
After a bit of digging, it looks like when I do the seek, mpegtsmux receives a GST_EVENT_SEGMENT but does not forward it to the fakesink.  mpegtsmux passes the event to gst_collect_pads_event_default(), which explicitly drops it if it's a new segment.

Is this expected behaviour? How should I correctly handle seeking in a pipeline like this? I tried a couple of other muxers (avi and qt) and got similar results. Does this imply that I can't do seeks if there's a muxer (or similar) in the pipeline? Thanks.