Вы используете устаревший браузер. Этот и другие сайты могут отображаться в нем неправильно. Необходимо обновить браузер или попробовать использовать другой.
Подскажите какая строчка в конфиге отвечает за включение парковочного режима? Я не хочу чтоб он у меня уходил в парковочный режим, поменял в конфиге AutoParking=1 на AutoParking=0, но все равно через 10 минут переходит в парковку :unknown:
Недавно sKov (если ошибся в написании - извиняюсь) проводил свои опыты и показал, что у него при любых параметрах (даже если в скобках - 0) все работает одинаково.
На новой кастомной прошивке все аналогично. В тестах не обнаружено влияние этой цифры на что-либо при стандартной строке запуска медиасервера. Если кто-то может указать условия тестирования (которые можно повторить и проверить), при которых рег виснет или еще как-то реагирует на этот параметр - отпиши, плз, буду сильно благодарен. Относительно максимального битрейта. Про это я тоже уже писал. На 720р это 25М, а для 1080p это 20М. Повышение битрейта выше этих параметров приводит к пропуску кадров при записи. Это хорошо видно по параметрам видеофайла, (которые можно посмотреть, например, в KMPlayer) Уже для 20М (1080p) минимальный фреймрейт составляет 15 кадров в секунду,а средний - около 28. Это еще приемлемо, хоть иногда там и есть пропуски кадров. Но если задирать битрейт выше, то можно увидеть минимальный фреймрейт в 2 кадра в секунду, а это уже очевидные и заметные пропуски кадров. Плюс заметный нагрев рега. На мой взгляд это уже неприемлемо. После долгих анализов разных тестов пришел к выводу, что большой разницы между 720р(25М) и 1080p(20М) не видно, но решил остановиться на последнем варианте. Иначе зачем этот full HD вообще нужен. Раз купил - надо пользоваться И еще у меня вопрос к всезнающему All-у. В случае конфликтной ситуации на дороге хочется сразу понимать, кто виноват и что делать. Т.е. сразу посмотреть запись рега. Сейчас приходится ездить с айпедом-мини и качать по вайфаю файлы. Это долго и неудобно. Удобнее вытащить флешку из рега и вставить ее в какой-то девайс, который умеет проигрывать full HD и имеет разъем под нашу карту. Кто что может посоветовать из бюджетных вариантов для такой операции?
Так вот в конце прошлого 2012 года я преспокойно ехал по этой давно-знакомой дороге со скоростью около 100-110 км/ч. Постепенно доганял едущий впереди Форд Фокус. Догнав его я перестроился для обгона, но этот "нехороший человек", не включая поворотника налево начал поворачивать (съезд с дороги в поле). Итог - я на тормозах оказываюсь в нем (при скорости в 90 км/ч. было-бы тоже самое).
А знак какой нибудь со стороны поля при выезда на главную стоял? Если да - то обгон на перекрестке. Вы ударили его взад или в бок? Если в бок - то перед любым маневром он должен удостовериться в его безопасности, и не важно включал он что-либо. Если в зад - то вина ваша, не соблюдали дистанцию. Рекомендую ездить с включенными фарами ближний, туманки, чтобы Вас было видно на дороге. Или как в Египте перед маневром включать все что есть + ещё и сигналить
Если вы внимательно следите за этой веткой (и по 400), то видите, что как раз основной информации (исходной от разработчиков) получить до сих пор не удается и слава нашим разработчикам (и их помощникам-энтузиастам), что они проводят эксперименты на своих регистраторах и постепенно (и успешно!) грызут "гранит науки". Поэтому первое, о чем стоит подумать, когда выявляется какой-то "ляп" в новой прошивке - это об уважении к их труду, а иногда выскакивающие ошибки только из-за того, что просто времени не хватает на полномасштабные и нудные испытания, да и мы все время торопим - дайте нам эту новую прошивку. По большому счету за это время прогресс налицо и кто попробовал кастом прошивку уже вряд ли вернется на стоковую. Ну а издержки при движении по неизведанному пути всегда будут.
С этим нельзя не согласиться. Именно поэтому и писал про чёрный ящик.
Торопить разработчиков - это всегда плохо. Ничего, кроме раздражения, это у них не вызывает. А торопЯщие могут быть вознаграждены бОльшим количеством багов.
Вопросы разные бывают. Т.к. у нас нет системы отчёта об ошибках, то люди пишут прямо в этом форуме. Какая-ни-какая, но обратная связь всё же, должна помогать отлавливать баги и исправлять недочёты. Другие имеют тот самый юношеский максимализм и пытливый ум, и им мало доступной инфы. Третьи, правда, к сожалению, предъявляют претензии. Но в совокупности, хоть и нелегко отделять зёрна от плевел, формируется знание у всего форума и каждого из учасников в отдельности. А это не может быть плохо.
Tehnik, да, заметил, битрейт не постоянный. И битрейт видеофайла не превышает установленный в одноимённном параметре. Значит, вся указываемая дельта (продолжим использовать такое название) используется внутри рега и не влияет на суммарный битрейт видеофайла: битрейт = (видео+аудио) - дельта?
Если внутри выделяем полосу битрейт+дельта и делаем оба параметра достаточно большими, то можем превысить максимальную пропускную полосу какой-нибудь внутренней обработки. Т.е. или начинка (железо или/и софт) не в состоянии заполнить дельту, и тогда нет проблем, или в состоянии - и тогда рег может зависнуть или выдать сбойный файл. Вот VBR как раз и используется для того, чтобы исплючить переполнение. Вопрос лишь в том, насколько хорошо реализован алгоритм его работы. Что же касаемо самого битрейта, то по идее безграничное его повышение в случае VBR не будет иметь смысла. Максимальный поток данных с матрицы имеет определённую величину. И сколько бы много мы не указывали, метры в диаметре нашей трубы (битрейт) никак не заполнятся струёй воды садового шланга (поток с матрицы).
А знак какой нибудь со стороны поля при выезда на главную стоял? Если да - то обгон на перекрестке. Вы ударили его взад или в бок? Если в бок - то перед любым маневром он должен удостовериться в его безопасности, и не важно включал он что-либо. Если в зад - то вина ваша, не соблюдали дистанцию. Рекомендую ездить с включенными фарами ближний, туманки, чтобы Вас было видно на дороге. Или как в Египте перед маневром включать все что есть + ещё и сигналить
Значит всё-таки возможностей железа и софта не хватает для обработки потока с матрицы? Т.е. наоборот (по отношению к тому, что я писАл выше), сколько бы мы не повышали диаметр нашего садового шланга, ему всё рано никогда не вместить тот поток, что идёт по трубопроводу. Или просто мощности проца не хватает для обработки всей трубы...
А при нестандартной строке запуска медиасервера какие закономерности Вы смогли выяснить? Не могли бы Вы пожалуйста поделиться бОльшими подробностями Ваших экспериментов?
Если внутри выделяем полосу битрейт+дельта и делаем оба параметра достаточно большими, то можем превысить максимальную пропускную полосу какой-нибудь внутренней обработки. Т.е. или начинка (железо или/и софт) не в состоянии заполнить дельту, и тогда нет проблем, или в состоянии - и тогда рег может зависнуть или выдать сбойный файл. Вот VBR как раз и используется для того, чтобы исплючить переполнение. Вопрос лишь в том, насколько хорошо реализован алгоритм его работы. Что же касаемо самого битрейта, то по идее безграничное его повышение в случае VBR не будет иметь смысла. Максимальный поток данных с матрицы имеет определённую величину. И сколько бы много мы не указывали, метры в диаметре нашей трубы (битрейт) никак не заполнятся струёй воды садового шланга (поток с матрицы).
1920x1080x30 = 62 Мегабита. И это без учета глубины цвета. Если там 24 бита, то умножаем на 3, соответственно. В реальности, конечно, несколько меньше, но все равно приличный такой поток данных идет. Даже в зеркалках RAW изображения сжимаются и, как ни печально, шумодавятся. Что уж говорить про видео. Не думаю, что стоит задумываться о потоке с матрицы )
Значит всё-таки возможностей железа и софта не хватает для обработки потока с матрицы? Т.е. наоборот (по отношению к тому, что я писАл выше), сколько бы мы не повышали диаметр нашего садового шланга, ему всё рано никогда не вместить тот поток, что идёт по трубопроводу. Или просто мощности проца не хватает для обработки всей трубы...
А при нестандартной строке запуска медиасервера какие закономерности Вы смогли выяснить? Не могли бы Вы пожалуйста поделиться бОльшими подробностями Ваших экспериментов?
Думаю, мощности процессора за глаза и за уши хватает для обработки raw потока с матрицы. Все таки, там алгоритмы и архитектура заточены под данную операцию, чтобы справляться с ней без особой нагрузки. А вот сжатие и внутренняя буферизация видео как раз и могут быть камнем преткновения.
1920x1080x30 = 62 Мегабита. И это без учета глубины цвета. Если там 24 бита, то умножаем на 3, соответственно. В реальности, конечно, несколько меньше, но все равно приличный такой поток данных идет. Даже в зеркалках RAW изображения сжимаются и, как ни печально, шумодавятся. Что уж говорить про видео. Не думаю, что стоит задумываться о потоке с матрицы )
Это всё верно для честной матрицы, где на каждый пиксель имеется хотя бы по одному активному элементу (не говоря уже про три - случай с 3CCD). Но это - дорогое удовльствие. На железо типа этого рега ставят всякие кастрированные (пардоньте, интерполирующие) матрицы. Так что эти рассчёты могут быть применимы лишь для рассчёта итоговой картинки - на выходе железного или софтверного кодера. Там мы по любому должны получить указанное количество пикселей при указанной глубине цвета в указанном в единицу времени количестве раз. А на вход может быть подан и один пиксель, который, в случае чёрного цвета, превратится в прекрасный FullHD квадрат Малевича.
Про проц не знаю, спеки не спотрел. Со всей архитектурой рега тоже не знаком. Обычно экономится всякая кеш-память, и - да, это может быть бутылочным горлышком. Значит опять надо вернуться к вопросу о максимально доупустимых значениях. Битрейт - 20 Мб/с, как было установлено SKov, а вот максимальная дельта?
Нет, честное. Это мы говорим об изображении, получаемом с матрицы. Если очень кратко, то возьмём, к примеру, фотоаппарат. Для т.н. 35 мм камеры идеальная матрица - размером с кадр на такой плёнке. А на самом деле матрицы имеют куда меньшие размеры. И иногда огромное количество мегапикселей реализуется на столь маленькой матрице, что каждый мегапиксель ловит шумов больше, чем полезного изображения (ведь для 1920x1080 достаточно 2073600 пикселей). Да плюс ещё проблемы с цветом. Для честного RGB надо иметь по три элемента на каждый пиксель. Всё что отличается от таких идеальных (и очень дорогостоящих в реализации) условий - достигается различными алгоритмами интерполяции и т.д.
Парни мне тут кинули по поводу софта андроида который не видит флешку. Вот попробуйте, если что то в шапку кину. heleg1 сказал:
Тут экспериментальным путем нашел решение проблемы, когда софт Blackvue для устройств на Android не видит SD карту по пути: /mnt/extsd Надо в корень SD-карты видеорегистратора добавить два пустых файла: punch_test sd_emulation После добавления этих файлов программа Blackvue позволяет выбрать SD-карту по пути: /mnt/extsd Проверил на двух планшетах Android (версии 4.0.4 и 2.3), на обоих помогло. Может кому-нибудь пригодится это решение.
Решил проверить на своем старом телефоне (SE Xperia X10 mini - Андроид 2.3.7) - не помогло... На Sony Xperia S - Андроид 4.0.4 все и так работает без каких-либо шаманств.
Удобнее вытащить флешку из рега и вставить ее в какой-то девайс, который умеет проигрывать full HD и имеет разъем под нашу карту. Кто что может посоветовать из бюджетных вариантов для такой операции?
У меня в бардачке этот валяется TeXet T-979HD Я его брал отремонтированный (новый) он меньше тысячи стоил. У этой фирмы есть чуть подороже 5 дюймов экран - серия 930
Убедился, что все образцы видео с разным бирейтом играет, но с ходу не нашел работает ли увеличение участка кадра (или видео). Но для обзорного просмотра вполне подходит.Сейчас не могу вспомнить, смог ли я на нем сделать копию видеофайла на другую флешку через его внутреннюю память. зы Вот нашел на 4PDA: Копировать из папки в папку, с карты в память и наоборот можно! На верхнюю шестеренку (самого верхнего файла) внутри выбранной папки, вставить. Целые папки с файлами можно копировать. Так что резервную копию можно оперативно без компьютера (ноутбука или планшета)сделать на месте. Нужно попробовать (на всякий случай).
У меня в бардачке этот валяется TeXet T-979HD Я его брал отремонтированный (новый) он меньше тысячи стоил. У этой фирмы есть чуть подороже 5 дюймов экран - серия 930 http://www.texet.ru/mp3/
Большое спасибо, отличные ссылки! (и 2St.Hidden тоже спасибо!) Да, TeXet за тысячу с небольшим хвостиком - это , похоже, оптимальный вариант. Просто я не хочу покупать никакой новой вычислительной техники, т.к. у нас на семью из двух человек 3 ноутбука/нетбука и 3 больших компьютера, не считая всяких айпедов. Айфон тоже не хочу покупать, да и дороговато. Так что TeXet - идеально. Если размахнуться на 2тыс. с хвостиком, то можно и с вайфаем купить. Интересно, что у меня есть старенький TeXet, ему года четыре, на нем стоит WinCE и навигационная программа. И у меня была мысль прокрутить на нем видео с рега. Но не получилось. Файлы он видит, но играть не хочет/может. Теперь понятно, что просто надо посвежее железяку взять. Кто-то спрашивал про другие мои исследования рега. Отвечаю. Пробовал включать-отключать CABAC. Появился бОльший разброс в размере файла (незначительный все равно), качество, на мой взгляд никак не изменилось (да и не должно вроде как). Честно говоря, у меня большие вопросы вызывает реализация компрессора в нашем реге. Что там корейцы намудрили - одному их корейскому богу известно. Я много лет занимался сжатием видео, в том числе и H264, и могу точно сказать, что видео, снятое на скорости, и видео, снятое на стоянке, должны отличаться (при примерно равном качестве) в десятки раз по объему сжатого файла. Ничего похожего мы не наблюдаем. Размер файла почти не меняется в зависимости от характера видео. Почему так сделано - сие есть тайна великая! Но не мне ее разгадывать, т.к. после многочисленных опытов у меня ослабла пружина картодержателя. теперь карточка не выскакивает из рега, только чуть высовывается, так что ногтями ее пока зацепить можно. Но тенденция мне не нравится. Перепайка картодержателя меня не очень пугает, но жаль времени. Так что из активных исследователей я ухожу