seek on filesrc with TS file

[Jan Schmidt]

On 19/5/21 7:19 pm, 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)

I think the weirdness here is from the `tsparse` element. The original 
purpose of that element was for taking DVB input with multiple MPEG-TS 
programs and splitting them out to select each program. As such, it's 
usually tested in push mode - when buffer output is driven by the source 
element. Using `queue` after `filesrc` makes that part of the pipeline 
operate in push mode (because queue operates in push mode). Using 
`pushfilesrc ! tsparse` would do the same. I think the seek problems are 
caused by `tsparse` because it's not normally used when playing back 
files. Nevertheless, the criticals point to a bug that needs fixing.

Unless you're dealing with multi-program MPEG-TS, you don't need the 
`tsparse` at all - the normal pipeline for playing MPEG-TS is just:

`filesrc ! tsdemux ! $decoders`

or, even more generically use `uridecodebin` to build your decoder 
pipelines like playbin does.

- Jan.


>
> 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