顯示廣告
隱藏 ✕
※ 本文為 XBUCKXMR 轉寄自 ptt.cc 更新時間: 2013-08-03 14:49:49
看板 Gossiping
作者 syura945 (○~)
標題 Re: [問卦] 有沒有不滿128M就無法存檔的八卦?
時間 Sat Aug  3 13:39:57 2013


※ 引述《file70042 (大変殘念)》之銘言:
: 有沒有不滿128M就無法存檔的八卦?
: 這是監視器的特殊設定嗎?
: 為啥一定要128M?
: 有沒有128M的八卦?

  我是不知道這家公司的DVR是不是真的這樣設計DVR的,
  資料滿128MB才寫入硬碟這種方法滿不可思議。

  DVR的確有斷電造成資料遺失的情況,
  但預多遺失幾個field的影像,不到一秒。

  我想很多人應該都有遇過異常關機,開機後作業系統要求檢查磁碟的情況,
  而且檢查完會在c槽新增一些從資料區dump出來的資料。

  檔案系統本身就有可以回復資料的資訊,
  以同樣128MB為例,使用最常見也最簡單的FAT32,
  假設在錄到64MB的時候斷電了,
  開機時可以看到EntryA的容量不足128MB,
  所以從EntryA對應的FAT表往後找可以找到斷電前
  最後寫入的位置是在編號為FAT_N+0x00200000-1的資料叢集。

  接下來從FAT_N+0x00200000-1這個叢集的32KB錄影資料往前找,
  可以找到影像檔頭,這樣就能知道斷電前最後寫入圖片位置,
  把這張不完整的圖片砍掉以後,再從這個位置往後錄影,
  一直到把128MB寫滿後再去更新Entry的容量資訊,
  完全不會有資料遺失的問題。

   EntryA                FAT編號             FAT內容       資料區        
   檔名:檔案A                 :                                          
   容量:0MB                   :                                          
   叢集開始位置:FAT_N -> FAT_N               FAT_N+1    -> 檔案A在資料區
                         FAT_N+1             FAT_N+2       佔用0x200000個
                              :                 :          叢集 (64MB)    
                         FAT_N+0x00200000-1  0xFFFFFFFF ->               

  正常的DVR隨時在寫入硬碟,
  如果這家公司真的是使用在ram裡面存滿128MB才寫入硬碟的方式,
  那我真的很佩服這家公司敢把DVR拿到市場上賣。

  DVR有很多種功能,而且大同小異,其中一種是動態錄影,
  也就是偵測到畫面有物件在移動的時候才開始錄影,這樣可以節省空間。
  幾年前有一則新聞是錄影畫面出現鬼影,一個人突然出現在畫面中間,
  這其實是因為那家DVR的動態偵測有bug,延遲了幾秒才發現畫面中有人。

  也因為動態錄影可以節省硬碟空間,
  若使用昇銳存滿128MB才寫入硬碟的方式,
  那遺失的可能就是超過一天的錄影資料。

  沒錄到影像是非常嚴重的問題,
  所以DVR裡面有很多用來保護自己的資訊,
  常見的有,開機、錄影、停止錄影,影像遺失,這些都屬於人為或異常記錄。

  整個辦案過程,軍檢就不用說了,從頭到尾都是胡說八道,
  桃檢也是非常落漆,在拖了兩個禮拜以後才公佈裡面有開機記錄,
  代表之前有斷電,這個推論雖然很合理,但存滿128MB才寫入硬碟就有點牽強。

  而且,即使昇銳公司的DVR真的是這樣設計,
  桃檢的說法仍然還是有盲點。

  桃檢在記者會說,攝影機線路脫落,影像陸續變成黑畫面,
  資訊兵發現後把攝影機線路接回去仍然沒有出現畫面,
  資訊兵最後決定把DVR斷電重開,影像才恢復正常。

  如果桃檢這個說法是真的,那桃檢就少說一個地方,

  在DVR裡除了有開機記錄,應該也有攝影機線路脫落時的影像遺失記錄。


  也許桃檢過兩天又在記者會說有影像遺失記錄也說不定,
  目前看到的偵辦方式就是從網路上質疑的部份見招拆招,
  網路上一開始就質疑的開機記錄,

  桃檢查了兩個禮拜才查到,我很難相信這是真的。

--
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 211.74.72.225
※ 編輯: syura945        來自: 211.74.72.225        (08/03 13:40)
※ 編輯: syura945        來自: 211.74.72.225        (08/03 13:41)
c8c812345678:專業文1F 08/03 13:42
jameshcm:現在硬碟這麼大又便宜,設定成"動態偵測錄影"是不太合理2F 08/03 13:42
taimu:有點屌3F 08/03 13:42
w328065:跟我想的一樣4F 08/03 13:42
jameshcm:我在 #1H_7-4W3 裡有提到,買一台同款的來測就知真假5F 08/03 13:43
hinet5566:專業推6F 08/03 13:43
hyuchi0202:就被皮卡丘打雷打壞了阿7F 08/03 13:43
VF17:只吐槽樓上 就算硬碟又大又便宜 要保存良好畫質持續一個禮拜8F 08/03 13:44
VF17:以上的紀錄,動態偵測錄影是一個使用者會選擇的方法
tonyscat:專業文!10F 08/03 13:45
liaon98:只好推了11F 08/03 13:45
jameshcm:現在16CH DVR搭配30FPS全時錄影,隨便都可以錄至少一個月12F 08/03 13:46
a61113:失望13F 08/03 13:46
abucat:推專業文,128m才寫入的機器誰要買14F 08/03 13:47
ian90911:推專業文15F 08/03 13:47
jameshcm:況且動態偵測錄影不適合禁閉室;全時錄影 7 天循環遠好過16F 08/03 13:47
gn00295120:國軍買阿17F 08/03 13:48
jameshcm:動態偵測錄影(冒著靈敏度過低遺失畫面的風險)錄 30 天...18F 08/03 13:48
lazo:就是不想讓人民知道真相啊19F 08/03 13:50
lampardoRio:689:第三方沒有想要的答案  阿不然是要第幾方20F 08/03 13:54
greedypeople:專業21F 08/03 13:56
vikisser:推專業文22F 08/03 13:59
innominate:不起訴書裡面就有廠商跟型號了,買一台試試不就知道?23F 08/03 14:00
innominate:或者如果有鄉民認識昇銳的R&D,問一下也可以知道
kenyun:事實上就是直接把檔案刪啦  再做個假檔25F 08/03 14:07
syura945:目前看來刪除檔案的可能性最大 因為不可能連檔案都沒有26F 08/03 14:09
syura945:以最低階320*240來算 128mb也存不了一個小時的影像
innominate:而且你寫的東西看起來就不像DVR的R&D,甚至連streaming28F 08/03 14:11
innominate:video recorder的概念都沒有
syura945:我想還沒人抓過未縮小影像畫面 但能壓到128mb的迷片30F 08/03 14:11
syura945:很可惜  我就是做DVR的  而且已經做了很多年
syura945:你覺得我哪個地方有講錯?
birdy590:據說檔案都是 pre-allocate 的... 要我設計也會是這樣33F 08/03 14:13
birdy590:總之 一旦斷電就會"沒關閉的影像檔全數丟失" 實在是很扯
syura945:預先分配的做法可有可無,那是看客戶做法,兩種都做過35F 08/03 14:14
innominate:你做DVR的,應該知道streaming video record基本上36F 08/03 14:14
innominate:都會用個buffer
birdy590:那又如何? streaming 也要切 block, 不可能滿 128MB 才寫38F 08/03 14:15
syura945:預先分配的優點只能少寫一個地方的資訊39F 08/03 14:15
birdy590:一般來講硬體 encoder buffer 都很小 編碼完馬上就要寫入40F 08/03 14:15
innominate:codec transport module會將資料送進buffer內41F 08/03 14:16
birdy590:每個鏡頭都集滿 128MB 才寫入 你的記憶體得多少才夠42F 08/03 14:16
syura945:這個例子要更新fat和entry  預先分配只要更新影像最後43F 08/03 14:16
innominate:不,buffer是在硬碟內,通常是一個circular buffer queue44F 08/03 14:16
birdy590:預先分配可以不更新 FAT table... 因為檔案早就開好了45F 08/03 14:17
birdy590:我敢打包票架構絕對不會是這樣... 對晶片來說硬碟不存在
birdy590:還circular buffer queue咧... 128MB 只是切割單位而已
innominate:http://0rz.tw/zaml648F 08/03 14:17
DVR Component FAQs
The DVR Module of the LEADTOOLS Multimedia API allows you to programmatically control the Capture module Capture object when capturing live video s... ...
 
syura945:DVR是4/8/16個攝影機共用60/120fields的編碼引擎49F 08/03 14:17
innominate:這是某家廠商的DVR component FAQ,自己看50F 08/03 14:18
birdy590:一個檔案用完就會跳到下一個 每個鏡頭分配的空間才是循環51F 08/03 14:18
innominate:自己看52F 08/03 14:18
innominate:Q:How does DVR buffering work?
innominate:A:The main purpose is to allow the capture of
innominate:compressed video streaming samples to a circular
birdy590:"implemented as a set of files under a given folder56F 08/03 14:20
syura945:http://ppt.cc/fS6G  你應該搞錯了57F 08/03 14:20
innominate:buffer queue on disk58F 08/03 14:20
birdy590:path" 是同一目錄下一群檔案去 rotate, 不是單一檔案59F 08/03 14:20
syura945:昇銳是用賣stand alone的機種  不是pc based60F 08/03 14:20
syura945:stand alone沒辦法做的像pc這麼靈活  越簡單越好
birdy590:其實 innominate 指的"circular buffer queue"就是我講的62F 08/03 14:22
syura945:stand alone機種不是用dsp就是用arm+code的solution63F 08/03 14:22
birdy590:只是他誤以為是單一檔案... 其實應該是一組檔案64F 08/03 14:22
syura945:birdy590你說的預先配置方法是很常見的 也是最簡單的65F 08/03 14:24
innominate:他是用一組檔案做circular buffer,但最終要寫入66F 08/03 14:24
birdy590:事實上是一直在寫入... codec 編碼出來馬上就要寫67F 08/03 14:25
innominate:實際檔案時,他是呼叫 CopyBufferToFile到檔案裡68F 08/03 14:25
birdy590:這種 solution 不可能有這麼多記憶體暫放編出來的影片69F 08/03 14:25
innominate:不是記憶體阿...buffer就是在硬碟70F 08/03 14:25
birdy590:換句話說 即使斷電應該也有很多寫到一半的影像檔可以用71F 08/03 14:25
syura945:我們以前的ram只有32MB  這樣就夠了72F 08/03 14:26
birdy590:那跟上面講的有何差別? 不是取個名叫 buffer 就比較高級73F 08/03 14:26
innominate:如果是用circular buffer,重開再錄就會被覆蓋74F 08/03 14:26
birdy590:說穿了就是 file rotate, 哪有這麼多複雜的名詞75F 08/03 14:26
innominate:重點是"circular buffer queue"76F 08/03 14:27
birdy590:而且因為是 pre-allocate, 即使斷電 FAT table 也是好的77F 08/03 14:27
innominate:你喜歡用甚麼名詞也好,但這些temp buffer files78F 08/03 14:27
birdy590:"circular buffer,重開再錄就會被覆蓋" 一組檔案搞不好79F 08/03 14:27
innominate:他們設計的目的就是buffer,不管你要叫他是file rotate80F 08/03 14:28
birdy590:容量有幾十 GB, 斷電重開機馬上蓋掉是哪招?81F 08/03 14:28
birdy590:不能直接跳下一個檔案嗎? 根本不是技術問題
syura945:pre-allocate的做法要加一個檔案記錄最後寫入位置83F 08/03 14:28
innominate:還是甚麼的,在沒有呼叫copyBufferToFile前84F 08/03 14:28
innominate:這些temp files就是有可能會蓋掉
syura945:所以我說只會比我講的例子少寫一個地方86F 08/03 14:29
birdy590:都說了是 pre-allocate, 哪來的 temp file87F 08/03 14:29
syura945:那是看怎麼設計的  我們會記錄最後寫入位置88F 08/03 14:29
innominate:本來就是看設計89F 08/03 14:30
syura945:所以重開還是能把資料救回來90F 08/03 14:30
innominate:我只是覺得有人認為全世界只有一種設計方式很詭異91F 08/03 14:30
innominate:除非重開機就立刻有救資料的機制
birdy590:當然不會只有一種設計方式 但是那種明顯有問題的誰會用?93F 08/03 14:32
file70042:我看不懂 冏94F 08/03 14:32
birdy590:救資料是一回事 重開機資料會馬上被覆蓋 這能接受?95F 08/03 14:32
innominate:你問我? 你應該去問昇銳吧?96F 08/03 14:32
EmptySmile:所以我昨天就講過...叫設計者公開怎麼弄得,不然都是猜.97F 08/03 14:33
birdy590:細節syura945已經講完了 明明是多記個數字就解決的事情98F 08/03 14:33
innominate:EmptySmile,桃檢本來就有傳喚昇銳的人作證了99F 08/03 14:35
innominate:當然,如果你一開始就完全不相信檢察體系,認為昇銳跟
innominate:桃檢聯手作偽證,那就只能信者恆信了
birdy590:這跟桃檢無關 而且並不難驗證 有昇銳機器的鄉民都可以做102F 08/03 14:36
birdy590:也不需要同樣型號, 因為軟體方面差異不至於太大
EmptySmile:我知道桃檢傳喚過,我也相信桃檢問過這種細節.104F 08/03 14:37
innominate:不同的型號可能用不同的solution,不同的firmware105F 08/03 14:37
innominate:怎麼會說差異不會太大?...
birdy590:以桃檢說明的詳細度 沒有提到這一塊(檔案到底是消失 還是107F 08/03 14:37
birdy590:被覆蓋 這點原廠 RD 一看便知 問題就是沒說)
birdy590:不同 solution 就算了, 不同 firmware 大概不會去動這個
innominate:桃檢的不起訴書裡面已經有提到了110F 08/03 14:38
birdy590:從鄉民貼的四路機種的檔案結構 應該是同樣的 solution111F 08/03 14:39
birdy590:哪裡有提到 就是沒有才會有現在這些問題
syura945:檔案系統通常不會被  不一樣的地方是影像檔頭113F 08/03 14:39
innominate:基本上已經排除檔案刪除跟覆蓋的問題114F 08/03 14:40
syura945:雖然我們有兩種檔案結構  但實際上原理都是一樣的115F 08/03 14:40
innominate:你要說在訊號線上動手腳這個還有得討論116F 08/03 14:40
innominate:但基本上桃檢的說明已經大致排除在硬碟動手腳
birdy590:正因為裡面描述的狀況太不合理... 如果是真的昇銳就腫了118F 08/03 14:41
syura945:訊號線我最後有提到  動這個應該會有影像遺失的記錄119F 08/03 14:41
birdy590:那是因為追查的方向根本就錯了, DVR 不是一般電腦的 OS120F 08/03 14:41
syura945:如果連這個都沒有  但有開機記錄  那就是關機關了80分鐘121F 08/03 14:41
innominate:如果訊號線根本沒問題就去重開機,那一樣不會有log122F 08/03 14:41
innominate:這部分是可以討論的
syura945:那就是關機關了80分了啊   這不需要查兩個禮拜吧124F 08/03 14:42
innominate:只是桃檢的不起訴書對檔案刪除變造的部分算說的很清楚125F 08/03 14:42
birdy590:例如說同樣是 FAT32, 存取的方式和 Windows 不見得會一樣126F 08/03 14:42
birdy590:以 DVR 系統設計的角度 這樣的結果很不合理 如果是真的
innominate:我不需要替桃檢背書他們為何要查這麼久啊128F 08/03 14:43
birdy590:這公司 PM 通通抓去 fire 掉都是應該的129F 08/03 14:43
syura945:windows除了不一定一樣  實際上fat裡面有一部分也沒說明130F 08/03 14:43
syura945:但windows的確會用到那一塊
birdy590:應該是"一定不一樣", 這類 RTOS 的 library 通常較簡陋132F 08/03 14:44
birdy590:簡陋不見得是壞處 說不定是好處(eg. FAT table 不易壞)
innominate:所以我說去追昇銳這點根本沒意義...134F 08/03 14:45
birdy590:當然有意義 因為需要的資訊並沒有(eg 斷電/復電時間)135F 08/03 14:46
innominate:有重開機的紀錄136F 08/03 14:47
birdy590:一斷電未關閉的檔案就會全數丟失 對昇銳的商譽是重大傷害137F 08/03 14:47
innominate:桃檢是由重開機的紀錄來判讀138F 08/03 14:47
innominate:昇銳並沒有出來喊冤不是?
birdy590:那是因為沒有人去把這件事捅開 捅開很可能就會跳出來了140F 08/03 14:48
innominate:也許吧,但這都是假設不是?141F 08/03 14:48
birdy590:你認為買 DVR 的如果知道 被搶劫的時候搶匪只要拔電源142F 08/03 14:48
birdy590:就可以安全脫身不留下影片 對於客戶來說可以接受嗎?

--
※ 看板: traume 文章推薦值: 0 目前人氣: 0 累積人氣: 76 
作者 syura945 的最新發文:
點此顯示更多發文記錄
分享網址: 複製 已複製
r)回覆 e)編輯 d)刪除 M)收藏 ^x)轉錄 同主題: =)首篇 [)上篇 ])下篇