potential race condition when seeking in Gstavdemux??

[Majaja]

Dear all:

I have a problem about gst-libav's seek.

The problem is I see a potential race condition but not so sure...

Hence I would like to ask why t will not happen or, if it will indeed,
should we fix it?

The possible issue I saw happens within the following 2 threads when
seeking.

thread 1. gst_ffmpegdemux_loop()

thread 2. gst_ffmpegdemux_src_event()

The scenario is when thread 2 receives the seek event, it executes
gst_ffmpegdemux_perform_seek().

Then the flush start gst_ffmpegdemux_do_seek()(most important of all is the 
av_seek_frame()) & flush stop are executed. 

At the meantime, thread 1 is reading a avpacket by av_read_frame().  


We can simplify the condition by:

thread 1:  av_read_frame(), both W/R to AVFormatContext
 
thread 2:  av_seek_frame(), both W/R to AVFormatContext

But I do not see any mutex is applied to prevent it from happening.

In fact, I met this problem when porting adaptive demux (DASH).

*At my side thread 1 will not enter the pause status by calling
gst_pad_pause_task() to suspend itself but merely fall into
av_read_frame().*

When thread 1 is busy in executing av_read_frame(), thread 2 has gone
through the seek.

Ideally I think it is safe that gst_ffmpegdemux_loop must be in pause when
thread 2 is doing seek.

Could anyone can give it an explain?

Thanks



--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/potential-race-condition-when-seeking-in-Gstavdemux-tp4674970.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.