2010-02-09 17 views
0

我有一個Theora視頻解碼器庫和應用程序在Windows(Intel x86架構)上使用VS-2008編譯。我使用這個設置來解碼theora比特流(* .ogg文件)。此解碼器庫的源代碼在FFMPEG v0.5源碼包中使用,並進行了一些修改,以便在windows-VS-2008組合中進行編譯。Linux-gcc編譯的C代碼輸出和MS-VS2008編譯輸出之間輸出1位差異的原因是什麼?

現在,當我解碼相同的theora比特流使用ffmpeg(V0.5)應用程序在Linux(Intel x86架構),我已經使用gcc構建,並獲得一些解碼輸出yuv文件,此輸出文件有1位差異從windows-VS2008安裝程序獲得的輸出,以及輸出文件的幾個字節的輸出,並非全部。我預計2個輸出是位匹配的。

我懷疑以下因素:

a)所述兩個編譯gcc和MS-VS2008之間的某些數據類型不匹配。?

b)我已經驗證代碼沒有使用像log,pow,exp,cos等任何運行時數學庫函數......但我的代碼仍然有一些操作,如(a + b + c)/3.這可能是一個問題嗎?

這個「除以三」或任何其他數字的實現可以在兩個設置中不同。

c。)某種舍入/截斷效應的發生方式不同嗎?

d。)我可以在Linux中將缺少的任何宏作爲makefile/configure選項丟失嗎?

但我不能縮小問題和修復它。

1.)我的懷疑是否有效,或者是否還有其他問題可能導致這兩種不同設置產生的輸出1位差異。

2.)我該如何調試和解決這個問題?

我想,這種情況下的差異在linux-gcc的設置和Windows MS編譯器之間的輸出,甚至可以是任何通用的代碼真正的(不一定是專門針對我的視頻解碼器應用的情況下)

任何指針將對此有幫助。

感謝,

〜AD

+0

是我的回答有幫助嗎?你是否解決了這個問題?怎麼樣? – osgx 2010-03-03 18:25:59

+1

@osgx:你的回答給了我指針,在配置ffmpeg時禁用mmx優化。構建完成後,它爲我工作。謝謝。 – goldenmean 2010-03-04 05:02:34

回答

1

我想,這樣的行爲可能來自x87/sse2數學。你使用什麼版本的gcc?你使用float(32位)還是double(64位)?數學在x87內部具有更多精度位(82),可以存儲在內存中

嘗試標誌爲gcc -ffloat-store; -msse2 -mfpmath = SSE

標誌的MSVC /fp:fast /arch:SSE2

+0

這篇文章中的相同問題的選項http://gcc.gnu.org/ml/gcc-help/2009-07/msg00417.html – osgx 2010-02-10 10:18:09

0

1,可能是一個不同的優化某些浮點LIB

2,它是一個問題嗎?

編輯:
看看gcc上的VS(http://msdn.microsoft.com/en-us/library/e7s85ffb.aspx)或「-fprecise-math」上的「/ fprecise」選項。

+0

@Martin Becket:我猜你在問,差別是一個問題。對於我來說,這是因爲這個forora dec的窗口應用程序是我用ffmpef源代碼創建的,應該是引用比特精確的,即ffmpeg輸出。 – goldenmean 2010-02-09 19:52:07

+0

我的意思是說,對於一個壓縮視頻流來說,一個像素的亮度差異是0.4%(1bit)?您應該可以嘗試使用各種/ fprecise開關 – 2010-02-09 19:53:47

+0

感謝指針優化和浮點庫行爲選項。我會檢查他們。 – goldenmean 2010-02-09 20:22:05

0

關於b),整數和浮點除法在C99中完全指定。 C99爲整數指定round-to-zero(早期標準左舍入方向實現定義)和IEEE 754浮點。

聽說VS2008沒有聲稱實施C99,這並沒有什麼幫助。實現定義至少意味着您可以編寫一些測試用例,並確保在您的編譯器中做出了哪些決定。

如果你真的關心這個問題,那麼如何將代碼輸出到一個單獨的文件中輸出詳細的曲線並檢查第一個區別的曲線?嘿,也許跟蹤甚至已經在那裏進行調試!

+0

@Pascal:是在每個模塊之前在兩個設置中添加轉儲/跟蹤,這是我所考慮的選項之一。繼續比較這些轉儲模塊,直到找到差異。但是我想在跳轉到詳細調試之前,通過一些更高級別的分析/調試來勾選清單,所有其他原因。 – goldenmean 2010-02-09 20:10:16