[FFmpeg-devel] h264 threading fate tests

[Clément Bœsch]

On Mon, Oct 01, 2012 at 11:50:19AM +0200, Clément Bœsch wrote:
> On Fri, Sep 28, 2012 at 11:07:54AM +0200, Clément Bœsch wrote:
> > On Mon, Apr 16, 2012 at 04:43:42PM +0200, Clément Bœsch wrote:
> > > Hi,
> > > 
> > > I recently setup a few fate instances to test the threading (2, 8, 16 and
> > > auto), and regularly one of the h264 conformance test fails; look at the
> > > yellow entries here for instance:
> > > http://fate.ffmpeg.org/history.cgi?slot=x86_64-archlinux-gcc-threads-8
> > > 
> > > The other day, I tried to run an automated git bisect run, but
> > > unfortunately testing the potential regression would requires to run
> > > something like "while true; do make fate-h264 -j20 THREADS=8; done" for
> > > around 15 minutes at least each time, and it might not even be reliable.
> > > 
> > > I'm not familiar at all with AVC decoding or threading in FFmpeg, but
> > > maybe someone has an idea of what could cause this?
> > > 
> > > Maybe I should just open an issue in the trac?
> > 
> > OK so here is some more information about that race. Since the failure
> > seems to be always the same (failing frame CRCs are identical), I dumped
> > both outputs and made a diff. Here it is:
> > 
> >     http://lucy.pkh.me/race.html
> > 
> > Basically, we can notice some ±1 byte of difference at times. The
> > generated outputs can be downloaded from that page.
> > 
> > Also, I was able the other day (purely by luck) to have a valgrind
> > backtrace triggering the problem. The output was flooded, but here is a
> > sample: http://pastie.org/4602183. BTW, it seems the test is using a frame
> > based threading.
> > 
> > BTW, we observe only two failing tests: h264-conformance-cama2_vtc_b
> > mostly, but at times h264-conformance-mr1_bt_a fails as well. The
> > information I gave above are related to h264-conformance-cama2_vtc_b only.
> > 
> > Still anyone to look into this? :(
> > 
> 
> More digging info: it seems the problem (or at least part of it) is around
> H264Context->ref_count[2] (frame-based threading), especially when copying it
> from the priv_data in lavc/h264.c:decode_update_thread_context():
> 
>     libavcodec/h264.c:1248:    copy_fields(h, h1, ref_count, list_count);
> 

I have no idea about that specific race, but it looks like there is
another one: simultaneous frame worker threads seems to call
ff_init_cabac_states() (conflict around ff_h264_lps_range accesses).

  worker thread -> decode_frame -> decode_slice -> init cabac states

So maybe moving ff_init_cabac_states() only once in the init or something
(even if not necessary) could help.

[...]

I may sounds repetitive, but no one familiar with the H264 decoder or the
threading available? :)

The script I proposed in the previous mail helps to trigger that case,
generally 10-15 attempts are enough, sometimes a bit more, but it's not
that complicated to reproduce, you just have to wait and it breaks
directly.

-- 
Clément B.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20121002/41b74c1e/attachment.asc>