seek on filesrc with TS file

[Mathieu Duponchelle]

Hey, probably worth filing an issue with a sample application / input,
note that accurately seeking MPEG-TS is a bit awkward, support was
implemented for scanning for keyframes in H264, but it is possible
there's a bug with that code and your particular elementary stream.

If at all possible I would recommend using a different container format,
if not then debugging will probably be needed, perhaps you can start
by trying with a different input sample, for example one of the transport
streams in the gst-validate media assets.

Best,

-- 
Mathieu Duponchelle · https://www.centricular.com <https://www.centricular.com>

On 5/19/21 11:19 AM, Marianna S. Buschle via gstreamer-devel wrote:
> I have generated the following test files:
>
> gst-launch-1.0 videotestsrc is-live=true pattern=ball num-buffers=300 !
> video/x-raw,framerate=30/1,format=NV12 ! timeoverlay ! x264enc
> key-int-max=30 speed-preset=1 tune=zerolatency ! video/x-h264,profile=high !
> mpegtsmux ! filesink location=test.ts -v -e
>
> gst-launch-1.0 videotestsrc is-live=true pattern=ball num-buffers=300 !
> video/x-raw,framerate=30/1,format=NV12 ! timeoverlay ! filesink
> location=test.raw -v
>
> And then they are played in a python app using parse_launch:
>
> "filesrc name=replay location=test.ts ! queue ! tsparse ! tsdemux !
> h264parse ! avdec_h264 ! videoconvert ! ximagesink sync=1 "
>
> "filesrc name=replay location=test.raw ! videoparse format=nv12 width=320
> height=240 framerate=30/1 ! videoconvert ! ximagesink sync=1 "
>
> I have however issues when trying to do seek operations in the H264 stream
> (with TS container).
>
> Without the `queue` after the filesrc I get:
>
> (gst_ctrl.py:183848): GStreamer-CRITICAL **: 11:08:08.431: pushing on pad
> replay:src but it was not activated in push mode
> 0:00:08.281698886 183848 0x7f21940098c0 WARN                 basesrc
> gstbasesrc.c:3127:gst_base_src_loop:<replay> error: Internal data stream
> error.
> 0:00:08.281735348 183848 0x7f21940098c0 WARN                 basesrc
> gstbasesrc.c:3127:gst_base_src_loop:<replay> error: streaming stopped,
> reason error (-5)
>
> With the `queue` I'm able to do a single seek operation with:
>
>         self.pipeline.seek(1.0, Gst.Format.TIME, 
>              (Gst.SeekFlags.FLUSH | Gst.SeekFlags.ACCURATE),
>              Gst.SeekType.SET, 0 , Gst.SeekType.NONE, -1)
>
> But subsequent calls to seek give me:
>
> 0:00:10.778992854 183974 0x7f5e1c35d960 WARN                 tsdemux
> tsdemux.c:917:gst_ts_demux_do_seek: Couldn't convert start position to an
> offset
> 0:00:10.779094440 183974 0x7f5e1c35d960 WARN              mpegtsbase
> mpegtsbase.c:1721:mpegts_base_handle_seek_event: seeking failed error
> 0:00:10.779115381 183974 0x7f5e1c35d960 WARN                 tsdemux
> tsdemux.c:974:gst_ts_demux_srcpad_event: seeking failed
> 0:00:10.779150565 183974 0x7f5e1c35d960 WARN                 tsdemux
> tsdemux.c:974:gst_ts_demux_srcpad_event: seeking failed
>
> I have no issues with seeking on the raw stream.
>
> Moreover if I try to STOP (set state to NULL) and then re-START (set state
> to PLAYING) the pipeline with the H264 encoded file I get:
>
> 0:00:18.206206460 184004 0x7f627800a000 WARN                 basesrc
> gstbasesrc.c:3127:gst_base_src_loop:<replay> error: Internal data stream
> error.
> 0:00:18.206265696 184004 0x7f627800a000 WARN                 basesrc
> gstbasesrc.c:3127:gst_base_src_loop:<replay> error: streaming stopped,
> reason not-linked (-1)
> 0:00:18.206345761 184004 0x7f627800a000 WARN                   queue
> gstqueue.c:990:gst_queue_handle_sink_event:<queue0> error: Internal data
> stream error.
> 0:00:18.206371178 184004 0x7f627800a000 WARN                   queue
> gstqueue.c:990:gst_queue_handle_sink_event:<queue0> error: streaming
> stopped, reason not-linked (-1)
>
> This works file for the RAW file
>
> Lastly, if I change the `filesrc` into `multifilesrc` I can perform multiple
> seeks in the H264 encoded file.
> But It jumps to weird positions in the file instead of going to the start.
>
> I have tried using Gst.SeekFlags.KEY_UNIT instead of Gst.SeekFlags.ACCURATE
> and trying seeking in BYTES instead of TIME, but seen no real difference...
>
>
>
> --
> Sent from: http://gstreamer-devel.966125.n4.nabble.com/
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel