+23 |
1814
52
|
+46 |
2479
88
|
+161 |
3764
45
|
Насчет форматов сжатия — кстати, не так крут тот же Н.265, как считается. Если использовать Н.264 с high profile 5.2, то сжимает как-то не особо хуже, а воспроизводится везде, в отличии от Н.265. Я так за нефиг делать пережал 45 мин видео 1080р в файл размером 700Мб(при исходнике в 4.5Гб).
Вот так с exFAT, 64 гига, Трансценд х633 в авто не прижился, а х300 работает на ура. Разница в том, что у того, который х300 работа с блоками 4К в два раза шустрее и он не тупит при переходе от файла к файлу.
Не нравится exFAT? можно отформатировать в FAT32 (правда, виндовс этого не умеет, вроде)
2. Мой регистратор не умеет работать на 64 гигах на FAT32 в любом виде. Сам не форматирует и чужое форматирование не понимает. К тому же карточка не заточенная под FAT32 от его использования дохнет на раз.
Так что самое простое решение использовать ту карточку, которая нормально переваривается, увы «сверхскоростная» оказалась не у дел.
При таком методе скорость бы была сразу раза в 3-4 меньше чем заявленный максимум. Потому как на один записанный кластер полезной информации пришлось бы перезаписать +1 кластер FAT +1 кластер Bitmap +1 кластер директории (те самые два байта)
По этому почти везде (если это конечно не fatfs какой-нибудь на avr, которому просто негде хранить буфер) запись метаданных происходит через определенный интервал времени или количество байт.
Если в вашем регистраторе это делается слишком часто — то вряд ли тут можно что-то сделать. И карты при таком раскладе должны дохнуть независимо от того fat там или exfat
Суть авторегистратора в том, что у него есть буфер (там два гига оперативы), но он сливает его как только так сразу, ибо это «чёрный ящик» и никто не знает когда и при каких условиях у него отнимут питание и именно этот момент является чуть ли не самым важным для сохранения в виде нормально закрытого файла.
Т.е. у типовой видеокамеры всегда есть время после нажатия на кнопку «выкл» и она подтупливает сбрасывая на карточку накопившиеся изменения, а тут никак, надо сразу.
Суть FAT32 в том, что изменение любого файла вызывает перезапись таблицы размещения. Т.е. записал два файла, два раза записал FAT и по одному разу прошелся по данным. А в exFAT, если не ошибаюсь, таблицы как таковой нет, всё размазано по диску. Т.е. меняем файл один раз и один раз меняем область данных и всё. Собственно контроллер карточки под такое и заточен и когда после форматирования под FAT32 таблицы пишутся в разы чаще, чем область данные, то не предназначенные для такого обильного общения сектора дохнут значительно раньше времени. Я не знаю как на картах до 32 гигов, но есть ощущение, что сектора под FAT там обрабатываются отдельно на уровне контроллера и имеют гораздо большее резервирование, чем в области данных.
Откуда взялось про 4к? Минимальный блок в СД-карте 512 байт. Кластер в ехФАТ 32кб. «рекомендуемый блок стирания» в линуксе для карт такого размера, обычно — 4МБ.
Я прекрасно знаю, как работает ФАТ32. И на низком уровне.
С exFAT практического опыта не было, но по факту там та же таблица. Только она — файл, как это в NTFS. В итоге даже после после форматирования все будет в том же самом месте.
Но жизнь она штука сложная и далеко не всегда укладывается в простые формулы.
Еще раз: я пробововал (да и не только я) и результат именно такой, какой я написал.
Карточки с низким рейтингом на 4К тупят при циклической записи.
Ты можешь тут вагон формул привести, а я тебе просто два видео с разных карточек. На одной есть разрывы, на второй нет.
И о чудо! разница между карточками как раз при тестировании «блоками 4К».
Если есть программа для тестирования «блоками 512 байт», то ссылочку плиз, ибо общеизвестные (о чудо) меньше чем 4К не предлагают. Собственно никто и не может доказать, что на карточке в 64 гига 128 миллионов адресуемых блоков (ага, а сколько их должно быть на 200 гиговой?).
Нет смысла рубить память на мелкие блоки, если сейчас одна фотка под 10 мегабайт идёт. Нафига на блоки по 512 байт заморачиваться?
Опять же рекомендую почитать для чего именно была разработана система exFAT и в чём её основная задача. Если бы это была FAT в другой обёртке, то карточки умирали так же часто, но именно на exFAT этого не происходит. И да, если форматнуть карточку продаваемую с exFAT в FAT32 или там NTFS, то карточка умирает довольно быстро. А на exFAT живёт, как и задумано производителем.
И да, если нет опыта работы с exFAT, то рекомендую для продуктивной дискуссии его приобрести, а то опять теорией пасти начинает.
Например у нас 40 мбит, делим на 8, получаем 5МБ сек, хватит 10 класса.
Если поток 80 мбит, соответственно, 10МБ сек.
Для чего нужно 40МБ или 60МБ в сек? Явно просто многократный запас в скорости.
Насчёт съемки в RAW полностью согласен, тут чем быстрее тем лучше.
50МБ хорошо, 100МБ лучше.
Я то скажу на каком именно реге такой поток, только 99%, что тут же последует камент, что «за углом на 12 амбе дешевле». Вангую просто.
Так что рег TrendVision TDR-718GP
А карточки для приличных регов обсуждаются здесь.
Достаточно просто купить «прожорливый рег» и тайное теоретическое знание, что «10 мегабайт/секунду должно хватить» пройдёт само по себе.
Проф фотики отлично снимают и 1080p и 4K, и в RAW фоткают.
А реги затыки устраивают, капризные.
А линейно, когда видео непрерывно пишется минут 10 и потом есть несколько секунд только на закрытие то и 10 класса сойдёт, а если времени потупить после кнопки «выкл» нет, то не хватает.
Дело в том, что такой размер и более будет более правильны для 4к.
А для FHD и старых карт с головой. Но там и 128 есть…
Если брать камеру с 4к, то явно 128 даже будет малова-то.
Хотя на экшен камере наверное нет такого функционала.
это «скоростная» серия?
На коробке указано 333x. И кто кого? 333 множим на 150 в итоге получаем 50.
карту нужно тестировать в условиях, где прочее железо не является узким местом.
автор все правильно сделал.
Все упирается в железо и драйвера
На флешке появилась папка «Coredump» которая весит 15.4гб и в ней файлы по 0.99гб и тип ISTP. Что за папка такая которая занимает половины памяти(если не секрет)?
Флешка сандиск ультра, на планшете.
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.