Нет уж. Операционная система линукс тогда, а не Андроид. В нативном коде нет ни одной нативной функции из NDK Android. Поэтому я считаю, что это уже не Андроид. Насчет скорости записи на носитель, современные девайсы справляются с такой нагрузкой, но объем материала ооочень большой.
Писать свое это выходит за рамки «Андроид может». Конечно мы уже сделали много своего всякого, и давно перенесли почти весь функционал в нативную область. Но это уже не совсем Андроид, точнее совсем не андроид.
Где возможно, zero-copy сделано. Кадры не одинаковые. Мысль о такой оптимизации посещала меня, но оказалось, что каждый кадр имеет свои метаданные, и они могут вообще ни разу не повториться. В ZIP писать параллельно нельзя, потому что он ждет открытие записи позиции и ее закрытие после внесения файла. Так он работает.
Там скорее всего это всё происходило на уровне ISP, т.е. отдельный модуль на процессоре, который занимается только обработкой картинки, включая сжатие, и надо было только успевать в ZIP складывать. На Андроиде мы получаем RAW-кадр полного разрешения и нам надо сформировать файл еще со всеми тегами. А если надо уменьшить нагрузку на накопитель, то надо с этим кадром что-то сделать, и делать приходится на центральном процессоре или ГПУ, что совсем другое по производительности, нагреву и потреблению ресурсов. Если бы был отдельно доступен ISP, я думаю, работало бы много шустрее всё.
Там была проблема, связанная с метаданными камеры, в статье это описано. Т.е. мы не можем формировать днг, пока не получили полную информацию от сессии захвата. Теоретически можно разнести это по углам, да, и формировать днг, для которых информация есть уже сразу после копирования буфера. Вижу, это действительно дало бы прирост. Но поднимать код для теста, чтобы это проверить, уже не буду. Просто буду иметь на будущее. Сейчас уже проведены работы по переносу всей обработки в нативную области, и большой успех уже достигнут. Но синхронизация все еще сохранена (это необходимо на будущее). В любом случае спасибо, на определенные мысли это навело.
Копирование в нативной области действительно занимает очень мало. А вот в области Java поболее будет, чем пара миллисекунд.
В том месте, где приходит буфер кадра, ничего не сделать и многопоток ничего не решает. Кадр находится в DirectByteBuffer и его задержка переполняет буфер сессии. И пока он не будет скопирован, его не отпустить. Следующий момент касается помещения в ZIP. А там важно открыть запись позиции поместить файл и закрыть запись позиции. Многопоток ломает файл. Контролировать многопоток это то же самое, что его не использовать.
Работнику удобно иметь и брутто и нетто зарплату одинаковыми, не надо ничего считать. Сколько в объявлении стоит, столько получи на руки. Работодателю выгодно все свалить на работника, проще бухгалтерия, больше понимания у работника, сколько он стоит.
Ну ладно, пусть считают и часть работодателя, только пусть делают это для каждой страны. А то я часто вижу, как в целях повышения процентов для России причисляют налоговую часть работодателя, а для той же Германии нет.
Разделение налоговой нагрузки, наверно, и сделано, чтобы числа не казались такими большими. Плюс это рождает какое-то противостояние работника и работодателя. А так противостояние было бы работника и государства. Государству это точно не надо.
Боюсь, что даже если налоговую часть работодателя снизят, я работнику из нее не добавлю ни цента. Поэтому работнику есть смысл бороться только за то, чтобы бОльшую часть налогов платил работодатель. А работодателю выгодно, чтобы все налоги взимались с работника.
Вы прежде, чем выделываться, посмотрели бы, какие методы подсчета есть в бухгалтерии и в какую сторону. Я посчитал со стороны зарплаты на руки. Кто-то считает со стороны расходов работодателя. Только часть работодателя считается с зп до уплаты налогов. Как раз таким методом, как посчитал я.
От какой суммы считаются взносы работодателя? От 2400 или от 2900? От 2400. От брутто зарплаты. Т.е. в бухгалтерии такая практика подсчета имеет место быть. Поэтому свои понты оставьте кому-нибудь другому. 1 - это 1700, 0,7 это всё остальное. Т.е. всё остальное это 70%.
Такая же практика подсчета бывает при подсчете налога дивиденды. Когда ты переводишь себе сумму и от нее считается налог, который необходимо уплатить.
Допускаю, что больше. В Германии я не погружаюсь в налоги работника, ибо меня заботит общая сумма за работника. А работника должна беспокоить только его часть налога. Сколько государство за него берет с работодателя его волновать не должно. Я считаю. Посчитать он это легко может, это не секрет. Но нах ему это, это вопрос.
Речь же о работодателе, а не о работнике. Что возвращает работник это его дело.
Введите в калькулятор 1700 евро на руки. И бундесланд Sachsen. И вы получите брутто 2400 евро. А ниже все расходы работодателя в размере 2900 евро. Вроде это и есть 70%.
В РФ с вас государство имеет 13%. В Германии 23-25% вроде. В Латвии 20-31% подоходный+10,5% социальный. Но там большое значение имеет необлагаемый минимум тоже. С минимальной зарплатой, подоходного налога может и не быть вовсе. И чем выше зарплата, тем выше подоходный налог.
В Германии не спрашивают, хочешь ли ты платить налоги. Налоговая или социальная служба считают сумму налога и снимают со счета. И их не волнует, что это за деньги, хватит ли вам расплатиться с поставщиками или какие там у вас финансовые трудности. Когда нам кажется, что налоговая обнаглела, мы пытаемся спорить, конечно. Но только один раз за 17 лет у нас получилось что-то вернуть. Там была ошибка налоговой.
Если вы в Германии живете, то вас это не должно удивлять.
Нет уж. Операционная система линукс тогда, а не Андроид. В нативном коде нет ни одной нативной функции из NDK Android. Поэтому я считаю, что это уже не Андроид.
Насчет скорости записи на носитель, современные девайсы справляются с такой нагрузкой, но объем материала ооочень большой.
Писать свое это выходит за рамки «Андроид может». Конечно мы уже сделали много своего всякого, и давно перенесли почти весь функционал в нативную область. Но это уже не совсем Андроид, точнее совсем не андроид.
Еще раз? Не понял вопроса.
Где возможно, zero-copy сделано.
Кадры не одинаковые. Мысль о такой оптимизации посещала меня, но оказалось, что каждый кадр имеет свои метаданные, и они могут вообще ни разу не повториться.
В ZIP писать параллельно нельзя, потому что он ждет открытие записи позиции и ее закрытие после внесения файла. Так он работает.
Как на андроиде. Поэтому это больше похоже на страдания, чем на съемку RAW.
Там скорее всего это всё происходило на уровне ISP, т.е. отдельный модуль на процессоре, который занимается только обработкой картинки, включая сжатие, и надо было только успевать в ZIP складывать. На Андроиде мы получаем RAW-кадр полного разрешения и нам надо сформировать файл еще со всеми тегами. А если надо уменьшить нагрузку на накопитель, то надо с этим кадром что-то сделать, и делать приходится на центральном процессоре или ГПУ, что совсем другое по производительности, нагреву и потреблению ресурсов.
Если бы был отдельно доступен ISP, я думаю, работало бы много шустрее всё.
Там была проблема, связанная с метаданными камеры, в статье это описано. Т.е. мы не можем формировать днг, пока не получили полную информацию от сессии захвата.
Теоретически можно разнести это по углам, да, и формировать днг, для которых информация есть уже сразу после копирования буфера. Вижу, это действительно дало бы прирост.
Но поднимать код для теста, чтобы это проверить, уже не буду. Просто буду иметь на будущее.
Сейчас уже проведены работы по переносу всей обработки в нативную области, и большой успех уже достигнут. Но синхронизация все еще сохранена (это необходимо на будущее).
В любом случае спасибо, на определенные мысли это навело.
Копирование в нативной области действительно занимает очень мало. А вот в области Java поболее будет, чем пара миллисекунд.
Нативной поддержкой от производителя. В новых айфонах будет ProRes RAW.
В том месте, где приходит буфер кадра, ничего не сделать и многопоток ничего не решает. Кадр находится в DirectByteBuffer и его задержка переполняет буфер сессии. И пока он не будет скопирован, его не отпустить. Следующий момент касается помещения в ZIP. А там важно открыть запись позиции поместить файл и закрыть запись позиции. Многопоток ломает файл. Контролировать многопоток это то же самое, что его не использовать.
Работнику удобно иметь и брутто и нетто зарплату одинаковыми, не надо ничего считать. Сколько в объявлении стоит, столько получи на руки.
Работодателю выгодно все свалить на работника, проще бухгалтерия, больше понимания у работника, сколько он стоит.
Ну ладно, пусть считают и часть работодателя, только пусть делают это для каждой страны. А то я часто вижу, как в целях повышения процентов для России причисляют налоговую часть работодателя, а для той же Германии нет.
Разделение налоговой нагрузки, наверно, и сделано, чтобы числа не казались такими большими. Плюс это рождает какое-то противостояние работника и работодателя. А так противостояние было бы работника и государства. Государству это точно не надо.
Боюсь, что даже если налоговую часть работодателя снизят, я работнику из нее не добавлю ни цента. Поэтому работнику есть смысл бороться только за то, чтобы бОльшую часть налогов платил работодатель. А работодателю выгодно, чтобы все налоги взимались с работника.
Вы прежде, чем выделываться, посмотрели бы, какие методы подсчета есть в бухгалтерии и в какую сторону. Я посчитал со стороны зарплаты на руки. Кто-то считает со стороны расходов работодателя. Только часть работодателя считается с зп до уплаты налогов. Как раз таким методом, как посчитал я.
Сумма налогов составляет 70% от зарплаты на руки.
От какой суммы считаются взносы работодателя? От 2400 или от 2900? От 2400. От брутто зарплаты. Т.е. в бухгалтерии такая практика подсчета имеет место быть. Поэтому свои понты оставьте кому-нибудь другому. 1 - это 1700, 0,7 это всё остальное. Т.е. всё остальное это 70%.
Такая же практика подсчета бывает при подсчете налога дивиденды. Когда ты переводишь себе сумму и от нее считается налог, который необходимо уплатить.
ЗЫ. Я и есть работодатель.
У вас есть претензии к Германии? Мне кажется, что социальная защита работника там даже слишком хорошая. Невыгодная мне как работодателю.
2900/1700 = 1,7. От зарплаты на руки.
Допускаю, что больше. В Германии я не погружаюсь в налоги работника, ибо меня заботит общая сумма за работника. А работника должна беспокоить только его часть налога. Сколько государство за него берет с работодателя его волновать не должно. Я считаю. Посчитать он это легко может, это не секрет. Но нах ему это, это вопрос.
https://www.nettolohn.de/rechner/netto-brutto-ergebnis
Речь же о работодателе, а не о работнике. Что возвращает работник это его дело.
Введите в калькулятор 1700 евро на руки. И бундесланд Sachsen. И вы получите брутто 2400 евро. А ниже все расходы работодателя в размере 2900 евро. Вроде это и есть 70%.
В РФ с вас государство имеет 13%. В Германии 23-25% вроде. В Латвии 20-31% подоходный+10,5% социальный. Но там большое значение имеет необлагаемый минимум тоже. С минимальной зарплатой, подоходного налога может и не быть вовсе. И чем выше зарплата, тем выше подоходный налог.
В Германии не спрашивают, хочешь ли ты платить налоги. Налоговая или социальная служба считают сумму налога и снимают со счета. И их не волнует, что это за деньги, хватит ли вам расплатиться с поставщиками или какие там у вас финансовые трудности.
Когда нам кажется, что налоговая обнаглела, мы пытаемся спорить, конечно. Но только один раз за 17 лет у нас получилось что-то вернуть. Там была ошибка налоговой.
Если вы в Германии живете, то вас это не должно удивлять.