2018-01-22 3:35 GMT+01:00 Marton Balint <c...@passwd.hu>: > > > On Mon, 22 Jan 2018, Carl Eugen Hoyos wrote: > >> 2018-01-21 23:48 GMT+01:00 Kieran Kunhya <kieran...@googlemail.com>: >>> >>> On Sun, Jan 21, 2018 at 10:06 PM, Carl Eugen Hoyos <ceffm...@gmail.com> >>> wrote: >>> >>>> 2018-01-21 22:45 GMT+01:00 Kieran Kunhya <kieran...@googlemail.com>: >>>> > On Sun, Jan 21, 2018 at 2:42 PM, Carl Eugen Hoyos <ceffm...@gmail.com> >>>> > wrote: >>>> > >>>> >> 2018-01-21 15:34 GMT+01:00 Kieran Kunhya <kieran...@googlemail.com>: >>>> >> >> >>>> >> >> Only that I can not reproduce without your patch (and that I have >>>> >> >> never seen this issue before). >>>> >> >> >>>> >> >> Carl Eugen >>>> >> >> >>>> >> > I cannot reproduce this issue with ffplay on Ubuntu Linux. >>>> >> > I would recommend running "make distclean" and recompiling. >>>> >> >>>> >> My last test was done with "make distclean". >>>> > >>>> > Does this happen in single threaded mode? >>>> >>>> Also happens with "ffplay -threads 1" >>>> >>>> > Are you able to run ffplay under tsan? >> >> >> Does ffplay work for you at all under tsan? >> >>>> ffplay does not like tsan here (segfaults), ffmpeg shows >>>> many thousand lines (!) of tsan output for the ssp files we >>>> have (first frame only): Do you want me to send them? >>> >>> >>> I can only conclude this is an ffplay problem. >> >> >> Then please give Marton (and Michael) a few days to >> comment. > > > I cannot reproduce this (I am on openSuSE 42.3, x86_64, gcc 4.8.5, > SDL-2.0.3).
Then it may be my system. > FFplay works here with tsan, it reports some data races, but frames are > being shown slowly but surely if ffplay is run with -noframedrop. As said, it works sometimes here. > Are you sure you applied the newest version of this patch and the > simple_idct template patch? Yes, and I also use SDL-2.0.3. Carl Eugen _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
