Приветствую. Если кто-то юзает ffmpeg для коррекций искажений на снимках/фреймах, то подскажите, пожалуйста - какой фильтр лучше брать? Подходящего нашел два - lenscorrection и lensfun, если первый есть из коробки, то для второго нужно пересобирать ffmpeg с поддержкой lensfun.

Оно того стоит? На руках обычный дерьмофон с люто гнущей пространство камерой, и сомневаюсь, что в lensfun базе есть соотвествующий профиль под мой телефон. Видимо, нужно будеть выводить параметры/коэффициенты руками. Какой фильтр лучше взять/где удобней этим заниматься? Ну и максимум доп инфы по теме - приветствуется.

Перемещено hobbit из general

Привет. Два вопроса не дают мне покоя, нужен ликбез:

1. Заметил, что моя камера на телефоне имеет странное (для меня) свойство - искажение реальных размеров объектов. Например, она смотрит на прямоугольный объект проходящий через центр матрицы камеры, второй конец объекта максимально близко к краю матрицы. Так вот размеры этого объекта искажаются, ширира прямоугольника (с 90гр углами в реальности), которая фокусируется в центре матрицы меньше, чем ширина того же прямоугольника на краю матрицы. Что за фокусы? В голову мне приходит мысль - видимо, дело в том, что матрица имеет плоскую форму, свет идущий под углом проходит большее расстояние от линзы до матрицы и успевает сильнее расшириться, отсюда искажение размеров. Если гипотеза верна, то должны быть какие-то продвинутые камеры с матрицами в виде полусферы, где длина между линзой и матрицой одинакова во всех направлениях. Если так, то как называются такие камеры?

2. Ну чистое любопытство - а что вообще для камеры/глаза означает сфокусироваться на объекте? Ну т.е. в чем физическое ограничение видеть через одну линзу с постоянной силой преломления на разных расстояних от нее? Что ещё меняется в характеристиках светового пучка кроме его ширины? Ну будет точка попадать разное количество светочувствительных датчиков, и? Если про глаз ещё можно подумать, что там голова «обучена» видеть образы определенной цепочкой нейронов (мол «жирнее» образ - уже не узнается), то какие проблемы делать это для камеры? Просто мысль - может при прохождении полихроматического света через линзу при некотором расстоянии свет превращается в красно-сине-зеленую какашку? А вот был бы свет монохроматическим, то проблем бы не было.

Перемещено leave из general

Привет. Остался вопрос от проекта (я уже его закончил, вместо автоматического размытия сделал всё руками по ключевым кадрам), хотелось бы на будущее прояснить.

Был видео клип, и одна картинка, которая накладывалась в желаемое место, отследил одну точку на видео, в композиторе заюзал Track Position ноду, использовал её для корректировки координат вставляемой картинки + speed выход подключил к ноде vector blur (которая и должна размывать исходя из скорости перемещения). Но никакого размытия нода не добавляла, не работает. В натроне так размывал.

Знакомая история? Баг в блендере? Какая-то крутилка в кишках?

PS: я не про размытие 3Д сцены, я про использование блендера в качестве композитора только.

Привет. Почему так происходит - на чистом блендерном проекте (на новом) если применить quick effects->smoke для теста, то дым моделируется, если же проект, где я что делал, сцену настраивал, то моделирование отказывается работать даже предустановленный быстрый эффект, где я ничего не крутил. Почему так, и как с этим бороться?

Привет. Столкнулся с проблемой, нужно выкрутиться как-то, ибо много работы может пропасть. В общем нужно вставить смоделированную сцену с потоком жидкости в реальную съемку, я все подготовил, перемещения там всякие по ключевым кадрам всякого вспомогательного. И когда начал возиться с моделированием жидкости, то столкнулся с проблемой - если объекты маленькие, то жидкость очень трудно моделируется, нужно увеличивать параметр Resolution Devision для увеличения количества точек в потоке, но время для моделирования улетает в космос. При этом на больших размерах проблема не возникает, достаточное количество точек несложно достичь при более низких значениях. Естественно, что размеры Domain я сжал максимально.

Что можно сделать? Как-то конвертировать все объекты и их параметры в больший масштаб (и все изменения в ключевых кадрах) или я как-то не понял моделирование жидкости и кручу не за ту ручку? Если Resolution Devision находится на каких-то разумных значения в интересах скорости (где-то до 300), то из эмиттера вылетают огромные шары, без внутреннего деления.

Звучит несколько сумбурно, наверное, но если кто-то возился с жидкостью, то поймет, думаю.

Привет. Пин сконфигурирован как вход с подтяжкой к земле, но МК сам кидает на него высокий уровень. В интернетах говорят, что надо USB отключить, но у меня оно и так отключено (в кубе нет ничего активного).

Ребята помогите, плата разведена уже, кидать соплю на другой пин - совсем не хочется. У меня была подобная история с PA15 пином на другом МК, там решилось установкой регистра AFIO->MAPR |= AFIO_MAPR_SWJ_CFG_1. Здесь, наверное, тоже какой-то фокус.

Привет. Есть кусок нитилоновой проволки (который вспоминает форму при около 70 градусах цельсия). Нужно придать ей нужную мне форму, которую он будет вспоминать. Как понимаю, нужно нагреть до около 400 градусов.

Так как кусок небольшой и попыток немного, то решил спросить у вас истории успеха - сколько выдерживать нагретой, окисляется ли (может нужна инертная среда) и тп. Инфа по поводу как-то не гуглится.

Перемещено leave из talks

Привет. Ребят, я с сетями не на «ты». Вопрос совсем нубский, наверное. Прошу показать направление - поставил на VPS (назовём его Y) tinyproxy, через него хожу с своего десктопа Z на условный сервер в сети X. Есть подозрение, что сервер X понимает, что Y всего лишь proxy прокладка, и реальный источник трафика - Z. Вопрос - как бы проанализировать трафик на выходе из poxy сервера Y на наличие там в заголовках каких-то следов, говорящих о реальном источнике Z? Т.е. отослать тестовый пакет, завернуть его на VPS’в файл, ну и распарсить для изучения. Как и чем это делается по уму? Ну и в идеале - может какие-то подсказки на тему что искать в заголовках.

Всякие google’ы и спец сервисы не находят меня за proxy.

Приветствую. Мьютексы не обеспечевуют sequentially-consistent порядок, т.е. если существуют два мьютекса, которые контролируют доступ каждый к своим данным, в некотором потоке сначала берем первый мьютекс, модифицируем, берем второй мьютекс, модифицируем. Для данного потока порядок четкий - сначала 1 затем 2, для остальных же потоков вполне может быть сначала 2 затем 1.

Вопрос, как сделать sequentially-consistent порядок для всех потоков? Идею выражу в коде:

#include <thread>
#include <mutex>
#include <cassert>
using namespace std;

#define WITH_FENCE 0

int a_data, b_data;
mutex a_mtx, b_mtx;
atomic_int cnt = 0;

void write_a() {
   lock_guard lck(a_mtx);
   a_data = 5;
#if WITH_FENCE
   atomic_thread_fence(std::memory_order_seq_cst);
#endif
}

void write_b() {
   lock_guard lck(b_mtx);
   b_data = 5;
#if WITH_FENCE
   atomic_thread_fence(std::memory_order_seq_cst);
#endif
}

void check() {
   while (true) {
      lock_guard lck(a_mtx);
#if WITH_FENCE
      atomic_thread_fence(std::memory_order_seq_cst);
#endif
      if (a_data) {
         lock_guard lck_1(b_mtx);
#if WITH_FENCE
         atomic_thread_fence(std::memory_order_seq_cst);
#endif
         cnt.fetch_add(1, memory_order_relaxed);
         return;
      }
   }
}

int main() {
   jthread t0(check);
   jthread t1(check);
   jthread t0(write_a);
   jthread t1(write_b);
   assert (cnt == 0  || cnt == 2);
}

Если WITH_FENCE == 0, то порядка не будет точно. Поможет ли WITH_FENCE = 1? Если поможет, то что будет, если будут и другие потоки, которые будут брать данные мьютексы без барьера, будет ли сохранен порядок пусть и с какими-то вмешательствами из других потоков в рандомных местах (вне единого порядка, значит каждый поток видит их по-разному), но все же можно будет сказать в отношении упорядоченных событий (которые с барьером), что условное событие 2 не происходит раньше 1? В общем велком, если написал спутанно последнюю идею, дайте знать, приведу пример.

UPD: для main нет четкого порядка, код поправил

Привет, нужна помощь зала. Захотел хотелку из названия темы, подумал, что нужно отнаследоваться от std’шного и удалить operator weak_ptr

#include <memory>
using namespace std;


template <typename T>
class Shared_ptr_without_weak : public std::shared_ptr<T> {
public:
  using std::shared_ptr<T>::shared_ptr;
  operator std::weak_ptr<T>() = delete;
};

int main() {
  Shared_ptr_without_weak<int> s(new int());
  weak_ptr w0(s);  // error: use of deleted function
  weak_ptr<int> w1;
  w1 = s;          // ok
}

Результат заставил задуматься, почему в случае с конструктором задумка работает (ошибка компиляции), а с оператором= нет? В обоих случаях (ctr, operator=) shared_ptr принимается в шаблонную функцию, а версия с weak_ptr - обычная функция, нешаблонная, по идее должна иметь более высокий приоритет, но увы, во втором случае что-то идет не так.

Здороваться не будем, сразу к делу - есть некий процесс/движок, который модульный и многопоточный, модули/плагины/so подцепляются/отцепляются в рантайме из любого ядра, в плагинах тоже крутится поток. В общем среда конкурентная,

Проблема вот в чём - из описания dlclose понятно, что завершение её вообще не гарантирует, что модуль выгрузился. В теории и промежутки между загрузить/выгрузить могут быть сколь угодно малыми. Как бы не получить какие-то битые данные в образе плагина (старый не успел выгрузиться, записи с другого ядра в каком-нибудь буфере ждут, а тут запрос на добавление плагина с последующей записью на другом ядре).

Можно ли как-то точно узнать, что плагин полностью выгрузился из адресного пространства, следующий dlopen даст девственно «чистую» память под сошкой? Т.е. я дернул dlclose, за что мне потом дергать в цикле чтобы понять, что процедура завершена полностью?

Привет, мужчины. Имеется вопрос, возник в ходе работы над завершением программы. Упрощаю до сути - имеется ли здесь data race?

#include <thread>
#include <mutex>
#include <vector>
#include <chrono>
#include <memory>
#include <iostream>
using namespace std;


class Thread_pool {
   vector<thread> th;
   mutex mtx;
   atomic_flag stop_flag;
   bool destruction_stage = false;
public:
   ~Thread_pool() {
      stop_flag.test_and_set(memory_order_relaxed);
      if (true) {
         lock_guard l(mtx);
         destruction_stage = true;
      }
      std::cout << th.size() << "is running" << endl; // 16
      for (thread &t : th)
         t.join();
   }
   bool add_thread(void(f)(atomic_flag *)) {
      lock_guard l(mtx);
      if (destruction_stage)
         return false;
      th.push_back(thread(f, &stop_flag));
      return true;
   }
} th_pool;


void tf(atomic_flag *f) {
   while (! f->test(memory_order_relaxed)) {
      this_thread::sleep_for(1s);
      for (int i = 0;  i < 3;  ++i)
         th_pool.add_thread(tf);
   }
}

int main() {
   th_pool.add_thread(tf);
   this_thread::sleep_for(3s);
}

Имеется разделяемй между потоками ресурс (сам пул в данном случае). Всё внимаение на деструктор пула - логично, что нельзя взять мьютекс и убивать всех не спеша, другой поток так же захочет этот мьютекс и случится deadlock, в нём я ставлю флаг, который не даёт конкурирующим потокам дальше как-то использовать данные, сразу выход в add_thread(). Расчёт на то, что мьютекс при котором флаг установлен - последнее в цепи его событий, ну а раз так, то ни один поток (кроме главного) не может после этого события данные использовать. Но я не уверен, например вот:

atomic_thread_fence imposes stronger synchronization constraints than an atomic store operation with the same std::memory_order. While an atomic store-release operation prevents all preceding reads and writes from moving past the store-release, an atomic_thread_fence with memory_order_release ordering prevents all preceding reads and writes from moving past all subsequent stores.

Т.е. если правильно понял, то atomic_thread_fence может гарантировать, что какая-нибудь запись не пролезет до него, а вот с простыми атомиками такой гарантии уже не будет. А мьютексы?

С санитарами собирал, data race не находят.

PS: ГПТ беседу не вывозит, нужно мнение кожаных экспертов.