potential race condition when seeking in Gstavdemux??

[Sebastian Dröge]

On So, 2015-12-20 at 16:36 -0800, Majaja wrote:
> 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().  

gst_ffmpegdemux_perform_seek() is taking the stream lock, which would
make sure that no data processing is happening at the same time in
another thread.

I might also be missing something though, do you still see a problem
although the stream lock is taken? Or is it taken in the wrong way?

-- 
Sebastian Dröge, Centricular Ltd · http://www.centricular.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20151221/7f869626/attachment.sig>