[FFmpeg-devel] h264 threading fate tests

[Clément Bœsch]

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? :(

-- 
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/20120928/bf17828e/attachment.asc>