gstreamer hang

[BrianEdmond]

Hi,

I am trying to play videos on a Nitrogen 6x board and after seeking back and forth for a bit I get the video to hang.  When this happens I see the following debug information from gstreamer:

0:00:14.285095335  4640    0x17050 WARN               aiurdemux aiurdemux.c:1461:gst_aiurdemux_perform_seek: Seek to 0:19:35.000000000.

0:00:14.285398335  4640    0x17050 ERROR              aiurdemux aiurstreamcache.c:335:gst_aiur_stream_cache_seek: Unexpect backward seek addr 314124288, cachestart 314213376, offset 0

Then I keep getting these messages:

0:08:45.342819395  4640    0xaf9a8 WARN               aiurdemux aiurstreamcache.c:267:gst_aiur_stream_cache_add_buffer: wait push try 512 SIZE 233472 232778

The video is still hung.  Has anyone see this before?

Thanks,

Brian

[BrianEdmond]

Hi,

I will try a few different video streams and let you know.

Brian

[LeonardoSandova]

Hi Brian,

How do you seek? with gplay? do you observed the same behaviour with other files?

Leo

[BrianEdmond]

I have my own player code and seek as follows:

gst_element_seek_simple(gs_data->pipeline, GST_FORMAT_TIME, GST_SEEK_FLAG_FLUSH | GST_SEEK_FLAG_KEY_UNIT, (int64_t)(event_data->time_elapsed*GST_MSECOND));

time_elapsed seems correct and the debug "Seek to 0:19:35.000000000" is the correct time to seek.  It happens with all of my files and usually takes a bit of seeking back and forth to duplicate.

Brian

[LeonardoSandova]

Can you take a look at the gplay source code(./tools/gplay/*) ? . To get the source code, do it through ltib (gst-fsl-plugins package). A bonus would be to do the same stress test using gplay :smileyhappy:

Leo

[BrianEdmond]

I have tested using gplay and I can duplicate the same issue with it.  If I keep seeing forward and backward for a few minutes I can get the video to hang and gplay quits as follows:

0:01:38.756373994  3882    0xc1d88 WARN               aiurdemux aiurdemux.c:3900:aiurdemux_push_pad_buffer: Pad audio push error type -2

0:01:38.758524661  3882    0x15700 WARN               aiurdemux aiurdemux.c:1461:gst_aiurdemux_perform_seek: Seek to 0:19:33.000000000.

0:01:38.763291661  3882    0xc1d88 WARN               aiurdemux aiurdemux.c:1287:aiurdemux_send_stream_newsegment: Pad audio: Send newseg 0:19:32.938434000 first buffer 0:19:32.561267000

0:01:38.768295994  3882    0xc1d88 WARN               aiurdemux aiurdemux.c:1276:aiurdemux_send_stream_newsegment: Timestamp unexpect, maybe a core parser bug!

0:01:38.768450661  3882    0xc1d88 WARN               aiurdemux aiurdemux.c:1287:aiurdemux_send_stream_newsegment: Pad video: Send newseg 0:19:32.938434000 first buffer 0:19:33.272100000

0:01:38.794804328  3882 0x30b383d0 WARN                     bin gstbin.c:2380:gst_bin_do_latency_func:<playbin0> did not really configure latency of 0:00:00.000000000

full screen size:1280x1024

0:01:38.798674327  3882 0x30b383d0 WARN             mfw_v4lsink mfw_gst_v4l.c:1422:mfw_gst_v4l2_display_init: Wrong display width information

0:01:38.798795994  3882 0x30b383d0 WARN             mfw_v4lsink mfw_gst_v4l.c:1426:mfw_gst_v4l2_display_init: Wrong display height information

[Playing  ][Vol=01][00:19:33/00:21:44][fps:2] Aborted by signal Interrupt...

I did not have it in the debugger to get any other info but I thought I would post the information.  The following message comes out a lot with GST_DEBUG setup even when things work but I am not concerned with the audio at this point.

0:01:38.756373994  3882    0xc1d88 WARN               aiurdemux aiurdemux.c:3900:aiurdemux_push_pad_buffer: Pad audio push error type -2

Brian

[LeonardoSandova]

Brian, there is another function called gst_element_seek, could you use it and report what you observed? This function is the most basic one, but you got more control on the parameters you send.

Leo

[BrianEdmond]

I tried gst_element_seek and I tried it the way gplay does things by using gst_event_new_seek.  All methods fail the same way after about 5-6 seeks.  When I use gst_event_new_seek it generates an ASYNC_COMPLETE event but in the case it fails I send the event and I never get the ASYNC_COMPLETE event.  It is like the internal pipeline is hung and can't recover.  I see no errors in the bus_call either.

Brian

[LeonardoSandova]

jackmao, any idea regarding the seek issue?

Leo

[jack_mao]

Hi,

      From the log, it seems the plugin code can't handle some corner case ,  gstreamer  do the seek according to the timestamp. Does this issue happen on the specific stream or any video stream?

      If it can easy reproduce on any stream, after reproduce it , we can submit to the R&D to take a look.

Jack

[marlonsmith]

Hey guys, I'm having problems seeking video as well.  Was this problem ever solved?

Thanks

Marlon