seek on filesrc with TS file

[GStreamer-devel mailing list]

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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[GStreamer-devel mailing list]

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
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[GStreamer-devel mailing list]

Hi,

Thanks for the suggestions.

A different container is not really a viable option.
Some parts of our pipeline need to be TS and we would therefore like to keep
TS all over instead of having to re-mux in some parts (fx to save/load
files).

I have tried to use:
https://gitlab.freedesktop.org/gstreamer/gst-integration-testsuites/-/blob/master/medias/defaults/mpegts/tron_en_ge_aac_h264.ts
and get exactly the same behavior.

First seek runs fine, subsequent seeks don't because `tsdemux` has problem
converting the time...

I have done key-frame seeking in TS for another app, because I can switch
outputs, and it is possible to make it work.
Though I remember it required some specific settings and a `h264parse` in
order to keep the necessary flags.

I will try debugging the `tsdemux` to find out exactly what goes wrong in
the 2nd seek: `tsdemux tsdemux.c:917:gst_ts_demux_do_seek: Couldn't convert
start position to an offset`

Though I can probably work around it for this specific case since I want to
use it for replay, so I dont expect to need multiple seeks, I just though it
was a very odd behavior...

Any idea why doing stopping and then trying to start the pipeline again
results in failed negotiation? (state=PLAYING then state=NULL and then
state=PLAYING again)
Maybe something to do with the linking of the tsdemux?



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[GStreamer-devel mailing list]

I have tried debugging the error from `tsdemux`, it comes from here:
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/blob/master/gst/mpegtsdemux/tsdemux.c#L919

And the source for that function is here:
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/blob/master/gst/mpegtsdemux/mpegtspacketizer.c#L2377

This is the debug info of the first seek, which works:

0:00:06.959642670 199456 0x7fe7a4019800 DEBUG                tsdemux
tsdemux.c:967:gst_ts_demux_srcpad_event:<tsdemux0:video_0_0041> Got event
seek
0:00:06.959684979 199456 0x7fe7a4019800 DEBUG                tsdemux
tsdemux.c:873:gst_ts_demux_do_seek: seek event, seek event: 0x7fe760013420,
time 99:99:99.999999999, seq-num 375, GstEventSeek, rate=(double)1,
format=(GstFormat)time,
flags=(GstSeekFlags)GST_SEEK_FLAG_FLUSH+GST_SEEK_FLAG_ACCURATE,
cur-type=(GstSeekType)set, cur=(gint64)0, stop-type=(GstSeekType)none,
stop=(gint64)-1, trickmode-interval=(guint64)0;
0:00:06.959698294 199456 0x7fe7a4019800 LOG                  tsdemux
tsdemux.c:890:gst_ts_demux_do_seek:<tsdemux0> Before seek, output segment
time segment start=0:00:00.125000000, offset=0:00:00.000000000,
stop=99:99:99.999999999, rate=1.000000, applied_rate=1.000000, flags=0x00,
time=0:00:00.125000000, base=0:00:00.000000000, position 0:00:03.925000000,
duration 99:99:99.999999999
0:00:06.959707360 199456 0x7fe7a4019800 DEBUG                tsdemux
tsdemux.c:901:gst_ts_demux_do_seek:<tsdemux0> After seek, update 1 output
segment now time segment start=0:00:00.000000000, offset=0:00:00.000000000,
stop=99:99:99.999999999, rate=1.000000, applied_rate=1.000000, flags=0x01,
time=0:00:00.000000000, base=0:00:00.000000000, position 0:00:00.000000000,
duration 99:99:99.999999999
0:00:06.959713536 199456 0x7fe7a4019800 DEBUG       mpegtspacketizer
mpegtspacketizer.c:2400:mpegts_packetizer_ts_to_offset: Searching offset for
ts 0:00:00.000000000
0:00:06.959716922 199456 0x7fe7a4019800 DEBUG       mpegtspacketizer
mpegtspacketizer.c:2407:mpegts_packetizer_ts_to_offset: pcr is in current
group
0:00:06.959720421 199456 0x7fe7a4019800 DEBUG       mpegtspacketizer
mpegtspacketizer.c:2445:mpegts_packetizer_ts_to_offset:
nextgroup:0x7fe7a001a6f0, prevgroup:(nil)
0:00:06.959722987 199456 0x7fe7a4019800 DEBUG       mpegtspacketizer
mpegtspacketizer.c:2452:mpegts_packetizer_ts_to_offset: In group or after
last one
0:00:06.959726146 199456 0x7fe7a4019800 DEBUG       mpegtspacketizer
mpegtspacketizer.c:2475:mpegts_packetizer_ts_to_offset: Using prev PCR 0
offset 375
0:00:06.959729468 199456 0x7fe7a4019800 DEBUG       mpegtspacketizer
mpegtspacketizer.c:2477:mpegts_packetizer_ts_to_offset: Using last PCR
101700000 offset 151527
0:00:06.959733665 199456 0x7fe7a4019800 DEBUG       mpegtspacketizer
mpegtspacketizer.c:2485:mpegts_packetizer_ts_to_offset: Returning offset 375
for ts 0:00:00.000000000
0:00:06.959742243 199456 0x7fe7a4019800 DEBUG             mpegtsbase
mpegtsbase.c:1357:mpegts_base_sink_event:<mpegtsparse2-0> Got event
flush-start
0:00:06.959749358 199456 0x7fe7a4019800 DEBUG             mpegtsbase
mpegtsbase.c:1357:mpegts_base_sink_event:<tsdemux0> Got event flush-start
0:00:06.959783354 199456 0x7fe7a4009060 DEBUG                tsdemux
tsdemux.c:3250:gst_ts_demux_push_pending_data:<tsdemux0:video_0_0041>
Returned flushing
0:00:06.959795268 199456 0x7fe7a4009060 DEBUG                tsdemux
tsdemux.c:3252:gst_ts_demux_push_pending_data:<tsdemux0:video_0_0041>
combined flushing
0:00:06.959801322 199456 0x7fe7a4009060 LOG                  tsdemux
tsdemux.c:3282:gst_ts_demux_push_pending_data: Cleared PES data. returning
flushing
0:00:06.959861517 199456 0x7fe7a4019800 DEBUG             mpegtsbase
mpegtsbase.c:1357:mpegts_base_sink_event:<mpegtsparse2-0> Got event
flush-stop
0:00:06.959871566 199456 0x7fe7a4019800 DEBUG             mpegtsbase
mpegtsbase.c:1357:mpegts_base_sink_event:<tsdemux0> Got event flush-stop
0:00:06.960077437 199456 0x7fe7a4019800 DEBUG       mpegtspacketizer
mpegtspacketizer.c:619:mpegts_packetizer_flush: Flushing
0:00:06.960096515 199456 0x7fe7a4019800 DEBUG       mpegtspacketizer
mpegtspacketizer.c:1946:_close_current_group: Closing group and resetting
current
0:00:06.960103353 199456 0x7fe7a4019800 DEBUG       mpegtspacketizer
mpegtspacketizer.c:1925:_append_group_values: First PCR:0:59:59.879411111
offset:375 PCR_offset:0:00:00.000000000
0:00:06.960107998 199456 0x7fe7a4019800 DEBUG       mpegtspacketizer
mpegtspacketizer.c:1930:_append_group_values: Last PCR: +0:00:03.766666666
offset: +151152
0:00:06.960111306 199456 0x7fe7a4019800 DEBUG                tsdemux
tsdemux.c:1959:gst_ts_demux_stream_flush: flushing stream 0x7fe7a001cce0
0:00:06.960114489 199456 0x7fe7a4019800 DEBUG       mpegtspacketizer
mpegtspacketizer.c:619:mpegts_packetizer_flush: Flushing
0:00:06.960126381 199456 0x7fe7a4019800 DEBUG       mpegtspacketizer
mpegtspacketizer.c:1946:_close_current_group: Closing group and resetting
current
0:00:06.960131801 199456 0x7fe7a4019800 DEBUG       mpegtspacketizer
mpegtspacketizer.c:1925:_append_group_values: First PCR:0:59:59.879411111
offset:376 PCR_offset:0:00:00.000000000
0:00:06.960135974 199456 0x7fe7a4019800 DEBUG       mpegtspacketizer
mpegtspacketizer.c:1930:_append_group_values: Last PCR: +0:00:03.833333333
offset: +153972

And here for the second, which fails:

0:00:09.914908872 199456 0x7fe754012d90 DEBUG                tsdemux
tsdemux.c:967:gst_ts_demux_srcpad_event:<tsdemux0:video_0_0041> Got event
seek
0:00:09.914957580 199456 0x7fe754012d90 DEBUG                tsdemux
tsdemux.c:873:gst_ts_demux_do_seek: seek event, seek event: 0x7fe74c004e00,
time 99:99:99.999999999, seq-num 601, GstEventSeek, rate=(double)1,
format=(GstFormat)time,
flags=(GstSeekFlags)GST_SEEK_FLAG_FLUSH+GST_SEEK_FLAG_ACCURATE,
cur-type=(GstSeekType)set, cur=(gint64)0, stop-type=(GstSeekType)none,
stop=(gint64)-1, trickmode-interval=(guint64)0;
0:00:09.914982068 199456 0x7fe754012d90 LOG                  tsdemux
tsdemux.c:890:gst_ts_demux_do_seek:<tsdemux0> Before seek, output segment
time segment start=0:00:00.125000000, offset=0:00:00.000000000,
stop=99:99:99.999999999, rate=1.000000, applied_rate=1.000000, flags=0x01,
time=0:00:00.000000000, base=0:00:00.000000000, position 0:00:03.491666666,
duration 99:99:99.999999999
0:00:09.915008650 199456 0x7fe754012d90 DEBUG                tsdemux
tsdemux.c:901:gst_ts_demux_do_seek:<tsdemux0> After seek, update 1 output
segment now time segment start=0:00:00.000000000, offset=0:00:00.000000000,
stop=99:99:99.999999999, rate=1.000000, applied_rate=1.000000, flags=0x01,
time=0:00:00.000000000, base=0:00:00.000000000, position 0:00:00.000000000,
duration 99:99:99.999999999
0:00:09.915014344 199456 0x7fe754012d90 DEBUG       mpegtspacketizer
mpegtspacketizer.c:2400:mpegts_packetizer_ts_to_offset: Searching offset for
ts 0:00:00.000000000
0:00:09.915018148 199456 0x7fe754012d90 DEBUG       mpegtspacketizer
mpegtspacketizer.c:2407:mpegts_packetizer_ts_to_offset: pcr is in current
group
0:00:09.915021668 199456 0x7fe754012d90 DEBUG       mpegtspacketizer
mpegtspacketizer.c:2445:mpegts_packetizer_ts_to_offset:
nextgroup:0x7fe7a001a720, prevgroup:(nil)
0:00:09.915024799 199456 0x7fe754012d90 DEBUG       mpegtspacketizer
mpegtspacketizer.c:2452:mpegts_packetizer_ts_to_offset: In group or after
last one
0:00:09.915028582 199456 0x7fe754012d90 DEBUG       mpegtspacketizer
mpegtspacketizer.c:2475:mpegts_packetizer_ts_to_offset: Using prev PCR 0
offset 18446744073709551615
0:00:09.915031580 199456 0x7fe754012d90 DEBUG       mpegtspacketizer
mpegtspacketizer.c:2477:mpegts_packetizer_ts_to_offset: Using last PCR
90900000 offset 135735
0:00:09.915036435 199456 0x7fe754012d90 DEBUG       mpegtspacketizer
mpegtspacketizer.c:2485:mpegts_packetizer_ts_to_offset: Returning offset
18446744073709551615 for ts 0:00:00.000000000
0:00:09.915039441 199456 0x7fe754012d90 WARN                 tsdemux
tsdemux.c:917:gst_ts_demux_do_seek: Couldn't convert start position to an
offset
0:00:09.915042629 199456 0x7fe754012d90 WARN              mpegtsbase
mpegtsbase.c:1721:mpegts_base_handle_seek_event: seeking failed error
0:00:09.915045761 199456 0x7fe754012d90 WARN                 tsdemux
tsdemux.c:974:gst_ts_demux_srcpad_event: seeking failed
0:00:09.915053277 199456 0x7fe754012d90 DEBUG                tsdemux
tsdemux.c:967:gst_ts_demux_srcpad_event:<tsdemux0:video_0_0041> Got event
seek
0:00:09.915056853 199456 0x7fe754012d90 WARN                 tsdemux
tsdemux.c:974:gst_ts_demux_srcpad_event: seeking failed

The problem seems to be this:
mpegtspacketizer.c:2485:mpegts_packetizer_ts_to_offset: Returning offset
18446744073709551615 for ts 0:00:00.000000000

Which is actually -1 and comes from here:
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/blob/master/gst/mpegtsdemux/mpegtspacketizer.c#L2453
which actually comes from this pcr_table:
pcrtable = get_pcr_table (packetizer, pcr_pid);

But no idea why that is -1 in the table, I don't actually know anything
about the mpegts internals...

Could it be that something is being set wrong after the first seek?







--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[GStreamer-devel mailing list]

Hey, as I said I think this would be best discussed in a gitlab issue,
with sample code / input :)

On 5/20/21 1:27 PM, Marianna S. Buschle via gstreamer-devel wrote:

> I have tried debugging the error from `tsdemux`, it comes from here:
> https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/blob/master/gst/mpegtsdemux/tsdemux.c#L919
>
> And the source for that function is here:
> https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/blob/master/gst/mpegtsdemux/mpegtspacketizer.c#L2377
>
> This is the debug info of the first seek, which works:
>
> 0:00:06.959642670 199456 0x7fe7a4019800 DEBUG                tsdemux
> tsdemux.c:967:gst_ts_demux_srcpad_event:<tsdemux0:video_0_0041> Got event
> seek
> 0:00:06.959684979 199456 0x7fe7a4019800 DEBUG                tsdemux
> tsdemux.c:873:gst_ts_demux_do_seek: seek event, seek event: 0x7fe760013420,
> time 99:99:99.999999999, seq-num 375, GstEventSeek, rate=(double)1,
> format=(GstFormat)time,
> flags=(GstSeekFlags)GST_SEEK_FLAG_FLUSH+GST_SEEK_FLAG_ACCURATE,
> cur-type=(GstSeekType)set, cur=(gint64)0, stop-type=(GstSeekType)none,
> stop=(gint64)-1, trickmode-interval=(guint64)0;
> 0:00:06.959698294 199456 0x7fe7a4019800 LOG                  tsdemux
> tsdemux.c:890:gst_ts_demux_do_seek:<tsdemux0> Before seek, output segment
> time segment start=0:00:00.125000000, offset=0:00:00.000000000,
> stop=99:99:99.999999999, rate=1.000000, applied_rate=1.000000, flags=0x00,
> time=0:00:00.125000000, base=0:00:00.000000000, position 0:00:03.925000000,
> duration 99:99:99.999999999
> 0:00:06.959707360 199456 0x7fe7a4019800 DEBUG                tsdemux
> tsdemux.c:901:gst_ts_demux_do_seek:<tsdemux0> After seek, update 1 output
> segment now time segment start=0:00:00.000000000, offset=0:00:00.000000000,
> stop=99:99:99.999999999, rate=1.000000, applied_rate=1.000000, flags=0x01,
> time=0:00:00.000000000, base=0:00:00.000000000, position 0:00:00.000000000,
> duration 99:99:99.999999999
> 0:00:06.959713536 199456 0x7fe7a4019800 DEBUG       mpegtspacketizer
> mpegtspacketizer.c:2400:mpegts_packetizer_ts_to_offset: Searching offset for
> ts 0:00:00.000000000
> 0:00:06.959716922 199456 0x7fe7a4019800 DEBUG       mpegtspacketizer
> mpegtspacketizer.c:2407:mpegts_packetizer_ts_to_offset: pcr is in current
> group
> 0:00:06.959720421 199456 0x7fe7a4019800 DEBUG       mpegtspacketizer
> mpegtspacketizer.c:2445:mpegts_packetizer_ts_to_offset:
> nextgroup:0x7fe7a001a6f0, prevgroup:(nil)
> 0:00:06.959722987 199456 0x7fe7a4019800 DEBUG       mpegtspacketizer
> mpegtspacketizer.c:2452:mpegts_packetizer_ts_to_offset: In group or after
> last one
> 0:00:06.959726146 199456 0x7fe7a4019800 DEBUG       mpegtspacketizer
> mpegtspacketizer.c:2475:mpegts_packetizer_ts_to_offset: Using prev PCR 0
> offset 375
> 0:00:06.959729468 199456 0x7fe7a4019800 DEBUG       mpegtspacketizer
> mpegtspacketizer.c:2477:mpegts_packetizer_ts_to_offset: Using last PCR
> 101700000 offset 151527
> 0:00:06.959733665 199456 0x7fe7a4019800 DEBUG       mpegtspacketizer
> mpegtspacketizer.c:2485:mpegts_packetizer_ts_to_offset: Returning offset 375
> for ts 0:00:00.000000000
> 0:00:06.959742243 199456 0x7fe7a4019800 DEBUG             mpegtsbase
> mpegtsbase.c:1357:mpegts_base_sink_event:<mpegtsparse2-0> Got event
> flush-start
> 0:00:06.959749358 199456 0x7fe7a4019800 DEBUG             mpegtsbase
> mpegtsbase.c:1357:mpegts_base_sink_event:<tsdemux0> Got event flush-start
> 0:00:06.959783354 199456 0x7fe7a4009060 DEBUG                tsdemux
> tsdemux.c:3250:gst_ts_demux_push_pending_data:<tsdemux0:video_0_0041>
> Returned flushing
> 0:00:06.959795268 199456 0x7fe7a4009060 DEBUG                tsdemux
> tsdemux.c:3252:gst_ts_demux_push_pending_data:<tsdemux0:video_0_0041>
> combined flushing
> 0:00:06.959801322 199456 0x7fe7a4009060 LOG                  tsdemux
> tsdemux.c:3282:gst_ts_demux_push_pending_data: Cleared PES data. returning
> flushing
> 0:00:06.959861517 199456 0x7fe7a4019800 DEBUG             mpegtsbase
> mpegtsbase.c:1357:mpegts_base_sink_event:<mpegtsparse2-0> Got event
> flush-stop
> 0:00:06.959871566 199456 0x7fe7a4019800 DEBUG             mpegtsbase
> mpegtsbase.c:1357:mpegts_base_sink_event:<tsdemux0> Got event flush-stop
> 0:00:06.960077437 199456 0x7fe7a4019800 DEBUG       mpegtspacketizer
> mpegtspacketizer.c:619:mpegts_packetizer_flush: Flushing
> 0:00:06.960096515 199456 0x7fe7a4019800 DEBUG       mpegtspacketizer
> mpegtspacketizer.c:1946:_close_current_group: Closing group and resetting
> current
> 0:00:06.960103353 199456 0x7fe7a4019800 DEBUG       mpegtspacketizer
> mpegtspacketizer.c:1925:_append_group_values: First PCR:0:59:59.879411111
> offset:375 PCR_offset:0:00:00.000000000
> 0:00:06.960107998 199456 0x7fe7a4019800 DEBUG       mpegtspacketizer
> mpegtspacketizer.c:1930:_append_group_values: Last PCR: +0:00:03.766666666
> offset: +151152
> 0:00:06.960111306 199456 0x7fe7a4019800 DEBUG                tsdemux
> tsdemux.c:1959:gst_ts_demux_stream_flush: flushing stream 0x7fe7a001cce0
> 0:00:06.960114489 199456 0x7fe7a4019800 DEBUG       mpegtspacketizer
> mpegtspacketizer.c:619:mpegts_packetizer_flush: Flushing
> 0:00:06.960126381 199456 0x7fe7a4019800 DEBUG       mpegtspacketizer
> mpegtspacketizer.c:1946:_close_current_group: Closing group and resetting
> current
> 0:00:06.960131801 199456 0x7fe7a4019800 DEBUG       mpegtspacketizer
> mpegtspacketizer.c:1925:_append_group_values: First PCR:0:59:59.879411111
> offset:376 PCR_offset:0:00:00.000000000
> 0:00:06.960135974 199456 0x7fe7a4019800 DEBUG       mpegtspacketizer
> mpegtspacketizer.c:1930:_append_group_values: Last PCR: +0:00:03.833333333
> offset: +153972
>
> And here for the second, which fails:
>
> 0:00:09.914908872 199456 0x7fe754012d90 DEBUG                tsdemux
> tsdemux.c:967:gst_ts_demux_srcpad_event:<tsdemux0:video_0_0041> Got event
> seek
> 0:00:09.914957580 199456 0x7fe754012d90 DEBUG                tsdemux
> tsdemux.c:873:gst_ts_demux_do_seek: seek event, seek event: 0x7fe74c004e00,
> time 99:99:99.999999999, seq-num 601, GstEventSeek, rate=(double)1,
> format=(GstFormat)time,
> flags=(GstSeekFlags)GST_SEEK_FLAG_FLUSH+GST_SEEK_FLAG_ACCURATE,
> cur-type=(GstSeekType)set, cur=(gint64)0, stop-type=(GstSeekType)none,
> stop=(gint64)-1, trickmode-interval=(guint64)0;
> 0:00:09.914982068 199456 0x7fe754012d90 LOG                  tsdemux
> tsdemux.c:890:gst_ts_demux_do_seek:<tsdemux0> Before seek, output segment
> time segment start=0:00:00.125000000, offset=0:00:00.000000000,
> stop=99:99:99.999999999, rate=1.000000, applied_rate=1.000000, flags=0x01,
> time=0:00:00.000000000, base=0:00:00.000000000, position 0:00:03.491666666,
> duration 99:99:99.999999999
> 0:00:09.915008650 199456 0x7fe754012d90 DEBUG                tsdemux
> tsdemux.c:901:gst_ts_demux_do_seek:<tsdemux0> After seek, update 1 output
> segment now time segment start=0:00:00.000000000, offset=0:00:00.000000000,
> stop=99:99:99.999999999, rate=1.000000, applied_rate=1.000000, flags=0x01,
> time=0:00:00.000000000, base=0:00:00.000000000, position 0:00:00.000000000,
> duration 99:99:99.999999999
> 0:00:09.915014344 199456 0x7fe754012d90 DEBUG       mpegtspacketizer
> mpegtspacketizer.c:2400:mpegts_packetizer_ts_to_offset: Searching offset for
> ts 0:00:00.000000000
> 0:00:09.915018148 199456 0x7fe754012d90 DEBUG       mpegtspacketizer
> mpegtspacketizer.c:2407:mpegts_packetizer_ts_to_offset: pcr is in current
> group
> 0:00:09.915021668 199456 0x7fe754012d90 DEBUG       mpegtspacketizer
> mpegtspacketizer.c:2445:mpegts_packetizer_ts_to_offset:
> nextgroup:0x7fe7a001a720, prevgroup:(nil)
> 0:00:09.915024799 199456 0x7fe754012d90 DEBUG       mpegtspacketizer
> mpegtspacketizer.c:2452:mpegts_packetizer_ts_to_offset: In group or after
> last one
> 0:00:09.915028582 199456 0x7fe754012d90 DEBUG       mpegtspacketizer
> mpegtspacketizer.c:2475:mpegts_packetizer_ts_to_offset: Using prev PCR 0
> offset 18446744073709551615
> 0:00:09.915031580 199456 0x7fe754012d90 DEBUG       mpegtspacketizer
> mpegtspacketizer.c:2477:mpegts_packetizer_ts_to_offset: Using last PCR
> 90900000 offset 135735
> 0:00:09.915036435 199456 0x7fe754012d90 DEBUG       mpegtspacketizer
> mpegtspacketizer.c:2485:mpegts_packetizer_ts_to_offset: Returning offset
> 18446744073709551615 for ts 0:00:00.000000000
> 0:00:09.915039441 199456 0x7fe754012d90 WARN                 tsdemux
> tsdemux.c:917:gst_ts_demux_do_seek: Couldn't convert start position to an
> offset
> 0:00:09.915042629 199456 0x7fe754012d90 WARN              mpegtsbase
> mpegtsbase.c:1721:mpegts_base_handle_seek_event: seeking failed error
> 0:00:09.915045761 199456 0x7fe754012d90 WARN                 tsdemux
> tsdemux.c:974:gst_ts_demux_srcpad_event: seeking failed
> 0:00:09.915053277 199456 0x7fe754012d90 DEBUG                tsdemux
> tsdemux.c:967:gst_ts_demux_srcpad_event:<tsdemux0:video_0_0041> Got event
> seek
> 0:00:09.915056853 199456 0x7fe754012d90 WARN                 tsdemux
> tsdemux.c:974:gst_ts_demux_srcpad_event: seeking failed
>
> The problem seems to be this:
> mpegtspacketizer.c:2485:mpegts_packetizer_ts_to_offset: Returning offset
> 18446744073709551615 for ts 0:00:00.000000000
>
> Which is actually -1 and comes from here:
> https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/blob/master/gst/mpegtsdemux/mpegtspacketizer.c#L2453
> which actually comes from this pcr_table:
> pcrtable = get_pcr_table (packetizer, pcr_pid);
>
> But no idea why that is -1 in the table, I don't actually know anything
> about the mpegts internals...
>
> Could it be that something is being set wrong after the first seek?
>
>
>
>
>
>
>
> --
> Sent from: http://gstreamer-devel.966125.n4.nabble.com/
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[GStreamer-devel mailing list]

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
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[GStreamer-devel mailing list]

Hi,

You were right about the `tsparse` being the culprid.

If I use:

filesrc name=replay location=test.ts ! decodebin ! videoconvert ! ximagesink
sync=1

the seek works fine multiple times.

And I have also found out that the problem of doing NULL and then PLAYING
again is that the pad from tsdemux gets removed on NULL and then gets added
again on PLAYING, but is missing being linked.
Seems that for some reason the Gst.parse_launch() handles the linking
automatically on the first run, but not afterwards...

And now I will also open a bug about this issue.
I just wanted to make sure first that it was not me using things wrong ;)



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[GStreamer-devel mailing list]

I have now opened
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1596 :)



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[GStreamer-devel mailing list]

On 21/5/21 4:22 pm, Marianna S. Buschle via gstreamer-devel wrote:

> Hi,
>
> You were right about the `tsparse` being the culprid.
>
> If I use:
>
> filesrc name=replay location=test.ts ! decodebin ! videoconvert ! ximagesink
> sync=1
>
> the seek works fine multiple times.
>
> And I have also found out that the problem of doing NULL and then PLAYING
> again is that the pad from tsdemux gets removed on NULL and then gets added
> again on PLAYING, but is missing being linked.
> Seems that for some reason the Gst.parse_launch() handles the linking
> automatically on the first run, but not afterwards...

Yes, that's exactly what happens - Gst.parse_launch() attaches a handler
that tries to connect new pads, but disconnects itself once it succeeds.

You can use : instead of ! as the link operator and it will keep trying
to link pads forever.

- Jan.

>
> And now I will also open a bug about this issue.
> I just wanted to make sure first that it was not me using things wrong ;)
>
>
>
> --
> Sent from: http://gstreamer-devel.966125.n4.nabble.com/
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[GStreamer-devel mailing list]

> You can use : instead of ! as the link operator and it will keep trying
> to link pads forever.

Yeps, thanks, works perfectly.

That is a very useful tip, I don't think I ever saw that being mentioned in
any documentation.



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel