0

Windows（Intel x86アーキテクチャ）でVS-2008を使用してコンパイルされたTheoraビデオdeocderライブラリとアプリケーションがあります。このセットアップを使用して、theora ビット ストリーム (*.ogg ファイル) をデコードします。このデコーダー ライブラリのソース コードは、FFMPEG v0.5 ソース パッケージから使用され、windows-VS-2008 の組み合わせでコンパイルできるようにいくつかの変更が加えられています。

ここで、gcc を使用して構築した Linux (Intel x86 アーキテクチャ) 上の ffmpeg(V0.5) アプリケーションを使用して同じ theora ビットストリームをデコードし、デコードされた出力 yuv ファイルを取得すると、この出力ファイルは、から取得した出力と 1 ビットの違いがあります。 windows-VS2008 セットアップ、およびそれも出力ファイルの数バイトであり、すべてではありません。2 つの出力がビット一致することを期待していました。

私は以下の要因を疑っています：

a.) 2 つのコンパイラ gcc と MS-VS2008 の間でデータ型の不一致がありますか?

b.) コードが log、pow、exp、cos などのランタイム数学ライブラリ関数を使用していないことを確認しましたが、それでも私のコードには (a+b+c)/3.Could のような演算がいくつか含まれています。これは問題になりますか？

この「3 で割る」またはその他の数値の実装は、2 つの設定で異なる場合があります。

c.) ある種の丸め/切り捨ての影響が異なって発生していますか?

d.) Windows セットアップには存在しない makefile/configure オプションとして Linux に存在するマクロが欠落している可能性はありますか?

しかし、問題とその修正を絞り込むことはできません。

1.) 上記の私の疑問は有効ですか、またはこれらの 2 つの異なるセットアップによって生成される出力にこれらの 1 ビットの違いを引き起こす可能性のある他の問題がある可能性があります。

2.) これをデバッグして修正するにはどうすればよいですか?

linux-gcc セットアップと Windows MS コンパイラの出力の違いに関するこのシナリオは、一般的なコードにも当てはまります (ビデオ デコーダ アプリケーションの場合に必ずしも固有ではありません)。

これに関しては、どんな指針も役に立ちます。

ありがとう、

-広告

4

3 に答える 3

1

私は、そのような振る舞いはx87/sse2数学から来るかもしれないと思います。どのバージョンのgccを使用していますか？float（32ビット）またはdouble（64ビット）を使用しますか？x87の数学は、メモリに格納できるよりも内部的に精度の高いビット（82）を持っています

gcc-ffloat-storeのフラグを試してください。-msse2 -mfpmath = sse

msvcのフラグ/fp:fast /arch:SSE2

于 2010-02-10T10:14:29.300 に答える
0

1、おそらくいくつかの浮動小数点ライブラリの別の最適化

2、それは問題ですか？

編集:
VS の "/fprecise" オプション ( http://msdn.microsoft.com/en-us/library/e7s85ffb.aspx ) または gcc の "-fprecise-math" を見てください。

于 2010-02-09T19:48:59.847 に答える
0

b) については、C99 では整数除算と浮動小数点除算が完全に規定されています。C99 は整数に対して round-towards-zero (以前の標準では丸め方向は実装定義のまま) を指定し、IEEE 754 を浮動小数点に対して指定しています。

VS2008 が C99 の実装を主張していないと聞いたので、これはあまり役に立ちません。少なくとも実装定義とは、いくつかのテスト ケースを作成し、どの決定がコンパイラで行われたかを確認できることを意味します。

これが本当に気になる場合は、詳細なトレースを別のファイルに出力し、最初の違いについてトレースを調べるようにコードをインストルメント化するのはどうですか? ねえ、おそらくトレースはデバッグ目的ですでにそこにあるでしょう!

于 2010-02-09T19:51:20.963 に答える