[FFmpeg-devel] different output in threaded code - linux vs mingw

Ramiro Polla ramiro.polla
Tue Oct 7 03:31:59 CEST 2008


Hi,

On Mon, Oct 6, 2008 at 10:24 PM, Gianluigi Tiesi <mplayer at netfarm.it> wrote:
> Hi all,
> I'm playing with make test, and I have found a non deterministic
> output in threaded code on mingw.
>
> I run:
> ./ffmpeg_g -y -flags +bitexact -dct fastint -idct simple -sws_flags
> +accurate_rnd+bitexact -b 500k -flags +mv4+part+aic -trellis 1 -mbd bits
> -ps 200 -bf 2 -f image2 -vcodec pgmyuv -i tests/vsynth2/%02d.pgm -an
> -vcodec mpeg4 -threads 2 ./tests/data/a-mpeg4-thread.avi

I think this is just good old issue517 [0]
It fails in the mpeg2-thread test as well, doesn't it?

> and I get different outputs on mingw at each run, while
> the output is always the same on linux.

That's odd. I never tried this test on a multiple core machine on
Windows, but I've always been able to reproduce it in Linux (and I can
no longer test since I'm now using virtualbox with no multiple core
virtualization).

> I've tested both using pthread and win32 native threads
>
> The attached files show the output of these vars in MPV_encode_picture:
>
> ((struct MpegEncContext *) avctx->priv_data)->qscale
> ((struct MpegEncContext *) avctx->priv_data)->current_picture.quality
>
> for mingw I've made 3 runs and I got 3 different values
>
>
> I also get bogus value for qscale if the printf is in a different
> place (2103561886 instead of -1)
>
> does it rely on some uinint data?

Ramiro Polla
[0] http://roundup.mplayerhq.hu/roundup/ffmpeg/issue517




More information about the ffmpeg-devel mailing list