我使用192 x 144和420v，BGRA格式的分辨率以25fps的速率從iPhone相機抓取幀圖像。在iPhone上更快，更高效地進行JPEG轉換和壓縮
我將CVImageBufferRef s轉換成UIImage s，然後調用UIImageJPEGRepresenation(image, compressionQuality)以獲得圖像的壓縮JPEG版本。
在樂器中使用Time Profiler，我可以看到75％的CPU時間用於獲取圖像的JPEG表示，導致我需要在應用程序中完成的其他操作導致速度變慢。
如果我將壓縮比設置爲1.0（即無壓縮），並且如果將其設置爲0.0（即，完全壓縮），花費更多，則花費更少的時間。
是否有更有效的方式從iPhone的相機獲取圖像的JPEG表示？
我可以在不將CVImageBufferRef轉換爲UIImage的情況下獲得JPEG表示嗎（因此可以剪出相當昂貴的Core Graphics繪圖操作）？
是關注應用程序的響應性還是需要實際的壓縮時間？將JPEG代碼封裝在一個塊中並將其放在背景隊列上怎麼樣？
好的吶喊，但它更多關於轉換所需的實際時間。這項工作已經分開完成（儘可能多的），但我不能通過套接字發送JPEG數據，直到它完成轉換... – Jasarien 2010-12-02 16:10:32
其實 - 這可能不是真的？它可能會過度構建問題，但您可以在後臺線程中啓動編碼，爲輸出緩衝區保留共享內存空間，然後在編碼時開始發送。在大多數非Wifi情況下，我認爲發送時間比編碼時間要長。如果你的緩衝區用完了數據 - 這應該沒問題，但大多數HTTP連接（我假設你正在發送數據）不超過至少30秒。顯然，這種方法的主要問題是需要進入CFNetwork的細節來分塊發送數據。 – makdad 2010-12-02 18:04:36
很抱歉，這並不是HTTP。這是對等體之間的直接UDP連接。由於開銷，TCP顯示性能受到影響。在編碼JPEG文件時對它們進行流式處理可能是需要研究的內容，但這是爲了模擬'視頻'（或者可能是MotionJPEG）來代替iPhone上不具備的更合適的視頻流API。我擔心流式傳輸JPEG是不夠的，因爲「幀」仍然只能在完全發送後才能顯示。 – Jasarien 2010-12-10 09:34:50
你需要壓縮它們嗎？之後你在做什麼？ – 2010-10-14 10:12:57
他們正在通過網絡發送給對方。網絡可能有所不同，3G，Wifi，EDGE等。沒有壓縮的圖像（即使在192 x 144）太大。 – Jasarien 2010-10-14 11:01:43
您可能想要檢查一些低複雜度的壓縮器，如JPEG-LS，以查看它們是否符合您的需求。通常JPEG-LS是無損的，但有一個接近無損的選項壓縮更多。 – gusbro 2010-10-18 18:55:32