Не-е-е… это не наш метод! Надо сначала 10%+1000 р., а потом «внимательно выслушав избирателей», с широкого барского плеча снизить до 3% + 300 р. — И все! Народ доволен! Правительство хорошее!
Если вы хотите оптимизировать передачу данных, то вам нужно будет переинициализировать эндпоинт канала передачи видеоданных и внутренние буфера контроллера с новыми параметрами. Это влечет за собой перезагрузку устройства и новое подключение к хосту.
Эм… может я конечно что-то в чем-то не понимаю (как я говорил, я U3V не копал), но мне кажется это неправильным и нелогичным — а если мы хотим поменять разрешение кадра? Это что же, перегружать камеру? А значит терять тщательно подобранные параметры камеры (например время экспозиции и настройки триггера)?
Исходя из того, что я вижу в наших исходниках — хост и камера договариваются об аналоге MTU, и дальше камера передает Leader + N*MTU + FinalTransfer + Header, из которых и собирается кадр.
5.2 Streaming Mechanism
5.2.3 Payload Sequence
The SI Payload Transfer Size, SI Payload Transfer Count and SI Payload Final Transfer1
Size and SI Payload Final Transfer2 Size registers describe the host´s requirements
concerning payload data layout. If the device has less payload data to send than expected by the
host it must complete the outstanding transfer(s) using short or zero-length packets.
The payload is divided into “equal sized blocks” + “final transfer1”+ “final transfer2”.
Properties of “equal sized blocks” are described by SI Payload Transfer Size and SI Payload
Transfer Count.
The maximum size of payload data in bytes the device may send can be calculated as follows:
maximum_size_of_payload_data_in_bytes = SI Payload Transfer Size * SI Payload Transfer
Count + SI Payload Final Transfer1 Size + SI Payload FinalTransfer2 Size
Таким образом, изменение размера кадра ведет к изменение TransferCount и FinalTransferSize 1/2, но никак не перезагрузке USB
И еще уточняющий вопрос, указаные в вашем вопросе изменяемые параметры, это, как я понимаю AOI (Area of interest — OffsetX, OffsetY, Width, Height). Вас только AOI интересует или просто первый пришедший на ум параметр?
Если только AOI — то тогда, в общем случае, не вижу необходимости заморачиваться, проще в такой задаче получить полный кадр и дальше программно работать только с заданым подкадром.
Быстрый поиск по открытой документации на сайте производителя показал только CameraLink камеру.
Цитата из документации:
The dual video mode allows two independent acquisition
frames (Frame A and Frame B) to be programmed with independent control of exposure
time, area of interest (AOI), subsampling, gain, offset and wide dynamic range parameters.
То есть с «железной» точки зрения задача решена… только вот «заданное разрешение» задается все таки до начала захвата… вернее задать-то можно когда угодно, только вот когда желаемый кадр придет?
С одной стороны, у интерфейса GenTL есть понятие Stream, которое означает что камера способна отсылать более чем один поток изображений, и, наверное, в теории, можно настроить камеру так как вы сказали.
Вопрос лишь в том, найдется ли такая камера, которая это будет поддерживать… честно, я таких камер не знаю, хотя в нашей компании мы (вроде) пытались сделать нечто подобное, причем только на одном потоке (но тут получатель был один). На сколько это было успешно — не знаю.
Так же, в стандарте GEV (и скорее всего U3V, я просто его изнутри не копал) с каждым кадром приходит header и trailer которые сообщают размер, смещение, формат пикселя, временнУю метку и прочее для каждого кадра.
Соответственно в общем случае, размер кадра не фиксирован, и может изменяться (ну вы понимаете, куда вас пошлют лентяи программисты, которых заставят отслеживать размер каждого кадра и менять выходной канал в соответствии с новым кадром :) ) — но это в пределах одного потока, который приходит по одному адресу (хотя в GEV никто не запрещает этому адресу быть Broadcast или Multicast).
GenTL это всё-таки Transport Layer.
GenICam, как стандарт, описывает только формат xml файла который определяет, по какому регистру лежит тот или иной параметр.
Так же среди прочих "модулей" вы не назвали модуль PFNC, без которого прием и передача изображения была бы не возможна, но, как и SFNC это только список рекомендаций по именованию параметров.
Ещё есть огромный недостаток в полной не связанности модулей GenTL и GenICam, и, зачастую, оторванности стандартов U3V, GEV и CameraLink друг от друга…
Хотя CameraLink он вообще не от мира сего… Стандарт который описывает только физику, а про программное обеспечение они практически забили.
Вот, кстати, где физическое вступление было нужным и ненужным одновременно (и его наличие было причиной отказа моей жены-гуманитария от чтения этого великого произведения) — Сами Боги, Айзека Азимова.
Возник вопрос по поводу первой утечки памяти…
Вполне вероятно (код не читал) классы Beam и MasterScore являются наследниками QObject (тут же у нас Qt код), а значит при создании экземпляра класса Beam в список "детей" MasterScore'а записывается этот экземпляр, который будет удалён по удалению "отца", а значит утечки не будет.
Хотя в любом случае код является "подозрительным".
Телевизор не смотрю, новостные сайты читаю очень-очень редко. Довольно часто случается ситуация что о последних новостях узнаю из 'bash.im'. Ну иногда заглядываю в GoogleNow
А можно пояснить вот этот момент из пункта про DKIM:
Но что если данные MTA окажутся скомпрометированными, и злоумышленник также получит возможность отправлять поддельные письма через эти серверы? Как установить подлинность отправителя в этом случае? На помощь приходит аутентификация писем.
Сервер отправитель формирует отпечаток заголовков письма с помощью хэш-функции и подписывает его, используя закрытый ключ.
А Сервер-отправитель (то есть поле smtp server в настройке моего почтового клиента) и MTA это разве не одно и тоже лицо?
По сообщению Михаила Паулкина суд первой инстанции они выиграли. ФАС сказала что пойдет выше. Продолжаем запасаться попкорном.
Было бы интересно почитать коментарии о судебном заседании. Ведь наверняка там были какие-нибудь перлы как с одной так и с другой стороны.
Ну что же, сегодня 27.05.2016 состоялось финальное заседание арбитражного суда Орловской области, на котором судья не согласилась с претензиями ФАС относительно нашего плаката с объявлением на языке программирования ))
Таким образом суд первой инстанции мы выиграли, но еще вчера представитель ФАС, открыто заявила, что будут обжаловать решение, и готовы идти до Высшего арбитражного суда.
Я так понимаю, у них (ФАС) денег куры не клюют, и они могут позволить себе такие расходы? Тогда мы тоже готовы продолжать ликбез и далее, если этого потребует ситуация
В свое время прочитал занятную книгу, Lynn Visson, Русские проблемы в английской речи
Lynn Visson — американка русского происхождения; с 1970-х годов профессор русского языка и литературы в американских университетах, а в последние двадцать с лишним лет — синхронный переводчик с русского и с французского языков на английский в ООН.
Кроме того, они часто бывают озадачены тем, почему у «негативно настроенных» русских столько «проблем». Дело в том, что слова «проблема» и problem не точно соответствуют друг другу по всем оттенкам смысла. На обоих языках это слово может означать вопрос, или дилемму, требующую решения. Но в определенном контексте эта русская «проблема» приобретает иное значение, и тогда ей гораздо более соответствуют issues или questions.
Во время командировок в Россию американцы часто слышат от того или иного русского коллеги, что им предстоит вместе c ним обсудить или решать «целый ряд проблем», а потом удивляются, почему, с их точки зрения, никаких problems не было. Оказывается, предлагавший собраться хотел обговорить то, что по сути означает ряд вопросов, тем, пунктов повестки дня, а по-английски называется: issues, questions, subjects, topics, agenda items, points, elements (for discussion). Что же касается слова problem, то оно для англоговорящего означает вопрос, по которому есть серьезные расхождения в позициях сторон или который будет сложно решить. Если таких спорных или сложных вопросов нет, то лучше не пугать собеседника и предупреждать не о «проблемах» (problems), а говорить: the list of items on our agenda / the subjects / topics for our discussion / talks / negotiations.
Эм… может я конечно что-то в чем-то не понимаю (как я говорил, я U3V не копал), но мне кажется это неправильным и нелогичным — а если мы хотим поменять разрешение кадра? Это что же, перегружать камеру? А значит терять тщательно подобранные параметры камеры (например время экспозиции и настройки триггера)?
Исходя из того, что я вижу в наших исходниках — хост и камера договариваются об аналоге MTU, и дальше камера передает Leader + N*MTU + FinalTransfer + Header, из которых и собирается кадр.
Ну вот, собственно и подтверждение: www.visiononline.org/userAssets/aiaUploads/file/USB3_Vision_Specification_v1-0-1.pdf (не исключаю что старый, просто первый попавшийся в гугле)
Таким образом, изменение размера кадра ведет к изменение TransferCount и FinalTransferSize 1/2, но никак не перезагрузке USB
Если только AOI — то тогда, в общем случае, не вижу необходимости заморачиваться, проще в такой задаче получить полный кадр и дальше программно работать только с заданым подкадром.
Цитата из документации:
То есть с «железной» точки зрения задача решена… только вот «заданное разрешение» задается все таки до начала захвата… вернее задать-то можно когда угодно, только вот когда желаемый кадр придет?
Вопрос лишь в том, найдется ли такая камера, которая это будет поддерживать… честно, я таких камер не знаю, хотя в нашей компании мы (вроде) пытались сделать нечто подобное, причем только на одном потоке (но тут получатель был один). На сколько это было успешно — не знаю.
Так же, в стандарте GEV (и скорее всего U3V, я просто его изнутри не копал) с каждым кадром приходит header и trailer которые сообщают размер, смещение, формат пикселя, временнУю метку и прочее для каждого кадра.
Соответственно в общем случае, размер кадра не фиксирован, и может изменяться (ну вы понимаете, куда вас пошлют лентяи программисты, которых заставят отслеживать размер каждого кадра и менять выходной канал в соответствии с новым кадром :) ) — но это в пределах одного потока, который приходит по одному адресу (хотя в GEV никто не запрещает этому адресу быть Broadcast или Multicast).
GenTL это всё-таки Transport Layer.
GenICam, как стандарт, описывает только формат xml файла который определяет, по какому регистру лежит тот или иной параметр.
Так же среди прочих "модулей" вы не назвали модуль PFNC, без которого прием и передача изображения была бы не возможна, но, как и SFNC это только список рекомендаций по именованию параметров.
Ещё есть огромный недостаток в полной не связанности модулей GenTL и GenICam, и, зачастую, оторванности стандартов U3V, GEV и CameraLink друг от друга…
Хотя CameraLink он вообще не от мира сего… Стандарт который описывает только физику, а про программное обеспечение они практически забили.
На сколько я помню, фраза была "звезда умерла, чтобы ты могла носить это кольцо" (говорится тоном защитников животных и прочих веганов)
Возник вопрос по поводу первой утечки памяти…
Вполне вероятно (код не читал) классы
BeamиMasterScoreявляются наследникамиQObject(тут же у нас Qt код), а значит при создании экземпляра класса Beam в список "детей"MasterScore'а записывается этот экземпляр, который будет удалён по удалению "отца", а значит утечки не будет.Хотя в любом случае код является "подозрительным".
А Сервер-отправитель (то есть поле smtp server в настройке моего почтового клиента) и MTA это разве не одно и тоже лицо?
Было бы интересно почитать коментарии о судебном заседании. Ведь наверняка там были какие-нибудь перлы как с одной так и с другой стороны.
Lynn Visson — американка русского происхождения; с 1970-х годов профессор русского языка и литературы в американских университетах, а в последние двадцать с лишним лет — синхронный переводчик с русского и с французского языков на английский в ООН.
Вот тут ее мнение о слове «проблема»:
www.e-reading.club/chapter.php/99688/10/Visson_-_Russkie_problemy_v_angliiiskoii_rechi.html
Кроме того, они часто бывают озадачены тем, почему у «негативно настроенных» русских столько «проблем». Дело в том, что слова «проблема» и problem не точно соответствуют друг другу по всем оттенкам смысла. На обоих языках это слово может означать вопрос, или дилемму, требующую решения. Но в определенном контексте эта русская «проблема» приобретает иное значение, и тогда ей гораздо более соответствуют issues или questions.
Во время командировок в Россию американцы часто слышат от того или иного русского коллеги, что им предстоит вместе c ним обсудить или решать «целый ряд проблем», а потом удивляются, почему, с их точки зрения, никаких problems не было. Оказывается, предлагавший собраться хотел обговорить то, что по сути означает ряд вопросов, тем, пунктов повестки дня, а по-английски называется: issues, questions, subjects, topics, agenda items, points, elements (for discussion). Что же касается слова problem, то оно для англоговорящего означает вопрос, по которому есть серьезные расхождения в позициях сторон или который будет сложно решить. Если таких спорных или сложных вопросов нет, то лучше не пугать собеседника и предупреждать не о «проблемах» (problems), а говорить: the list of items on our agenda / the subjects / topics for our discussion / talks / negotiations.