Перейти к содержанию
    

Ищем RTL-designer и соответствующего embedded-программиста удаленка Гонконг

В компанию

visharetech.com

на удаленную разработку Требуются:

1) RTL-разработчик на SystemVerilog минимум с опытом FPGA, желательно с опытом проектирования ASIC. Топология не требуется, максимум статический тайминг.

2) Соответствующий встраиваемый программист.

вилка зарплат 1000 USD - 3000 USD, сотрудничество долгосрочное по результатам первого проекта видеокодера 8К.

нижний уровень начальный опыт разработки FPGA, верхний - несколько лет опыта в полноценном коллективе с проектами ASIC/FPGA.

контакт - директор Ronald Hiu:  

mailto:[email protected]

Рональд был в России, на урале и в Казани, нанимал русского разработчика в Гонконгском офисе - специфику общения с русскими знает (у китайцев английский чаще хуже - поэтому вопрос коммуникации волнует)

 

ViShare Technology Limited is a venture-backed fabless semiconductor company focusing on developing low-latency wireless video transmission technology headquartered in Hong Kong. 
ViShare’s streaming chips deliver visual loss 4K video with 8ms latency and small bandwidth over LAN, WiFi and 5G. 
The technology can be widely applied to gaming streaming, wireless AR/VR and drone FPV(First Person View),  etc.

RTL-designer Responsibilities:

- Refine the project specification document 
- Perform architectural design
- Perform RTL coding, verification, and optimization
- System-level verification using software and FPGA prototype board.
- Interface with back-end ASIC design team for physical implementation.
- Prepare technical documentation

Requirements:

- Bachelor or above in Electronic Engineering or equivalent. 
- Must have good experience of FPGA/ASIC design
- Must have good experience of VHDL/Verilog; SystemVerilog is a plus
- Must have good skill in problem solving, teamwork and communication by English
- Knowledge of scripting languages such as Perl, TCL, and Makefile is preferable.


Programmer Responsibilities:
- Implement a RISC-V simulator with new features for fast multi-threading
- Port the Adaptive Transport protocol to the RISC-V platform 
- Develop a multi-core debugger
- Optimize simulation speed

# Requirements:
- Degree in computer science, or equivalent
- Strong C++ and OOP skills (ideally familiarity with newer language features, C++11, 14, 17)
- experience in multi-threaded and real-time programming
- knowledge in compiler tool chain
- fluent in spoke/ written English and good communication skill
- good analytical and interpersonal skills, team player
- experience on embedded platforms a bonus

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Вилка 1-3 К для 8К энкодера 30 fps, скорее всего HEVC и технология 5-7 нм (на 14 реально, но по потребляемой мощности не будет носимым), несерьёзно. Там только команда на 10 человек, если делать с нуля, займет год, но самим и хорошо.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

lexx

скорее всего HEVC

Подобный кодек, разрабатываемый отдельно от всей системы,  не позволит решить задачу для wireless AR/VR and drone FPV(First Person View), и 8ms latency - это слишком много. Соответственно до RTL ещё нужно дожить и нужны совсем другие специалисты.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В условиях стоит 8К кодек, все что ниже уже не подходит к задаче, следовательно это HEVC, VP9 или AV1. Последний отбрасываем ввиду сложности,  у VP9 проблемы как таковым, остаётся только HEVC.

Не обязательно использовать все фишки стандарта, оставьте только минимум. Полная поддержка декодера нам также не нужна, так что кромсаем все, что нам не нужно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

lexx

следовательно это HEVC, VP9 или AV1

Это не решается в рамках одного лишь кодека. Вот пример успешной разработки в этой области

https://www.amimon.com/medical-market/

Там принципиально иной подход используется.

И специалисты соответствующие

https://ieeexplore.ieee.org/author/37284132300

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1 hour ago, petrov said:

Это не решается в рамках одного лишь кодека.

Так приведите конкретные примеры, в ваших ссылках нет информации как производится кодирование.

Все самописные кодеки имеют один большой минус - они никем более не поддерживаются и тестирование очень затруднительно. Даже после нескольких лет вылизывания ни один референсный декодер не проходит промышленные тесты. 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

lexx

как производится кодирование

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

проходит промышленные тесты.

Это никак не помогает в устойчивом удалённом управлении без задержек, а наоборот.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1 hour ago, petrov said:

 

А почему 8 мс это много? Реакция человека на аудио-стимул около 200 мс, на видео - кратно больше в любое кол-во раз в зависимости от того, насколько данная визуальная информация нуждается в анализе..

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

6 minutes ago, Dr.Alex said:

А почему 8 мс это много? Реакция человека на аудио-стимул около 200 мс, на видео - кратно больше в любое кол-во раз в зависимости от того, насколько данная визуальная информация нуждается в анализе..

Поверьте, даже курсором мыши трудно становится управлять, если задержка измеряется сотнями мс.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

11 minutes ago, aaarrr said:

Поверьте, даже курсором мыши трудно становится управлять, если задержка измеряется сотнями мс.

Но я спросил про 8, а не про сотни.. Если монитор 60 Гц, это период 16 мс, соответственно задержка от 0 до 16 и среднее именно 8 мс  (если всё остальное вообще мгновенно, что вряд ли). Так вот откуда растут эти 8 мс :-)))) Только почему же всё-таки это много?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

On 11/5/2020 at 5:44 PM, petrov said:

Подобный кодек, разрабатываемый отдельно от всей системы,  не позволит решить задачу для wireless AR/VR and drone FPV(First Person View), и 8ms latency - это слишком много

Само по себе кодирование + декодирование видео много времени не отнимает (0.25ms Enc + 0.25ms Dec). Большая задержка (16 мс) возникает из-за необходимости компенсации сетевого джиттера для чего используют большой "Decoder Stream Buffer (DSB)".

Но при работе в режиме радиотрансляции точка-точка сетевой джиттер будет небольшим, поэтому "Decoder Stream Buffer (DSB)" можно сделать всего на несколько миллисекунд.

У cast-inc есть оценки "Latency In A Video Streaming Application": Understanding—and Reducing—Latency in Video Compression Systems

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В статье 0.25мс это одна строчка пикселей на 1080р 30 fps. На 60Гц как раз 8 энкодер и столько же декодер выйдет.

Статья откровенно странная, даже понятия свои автор придумал, выход декодера DPB decoded picture buffer. И единственное для чего он нужен - это усреднение производительности и хранение референсных данных для декодирования. И чем меньше кадров для временного хранения, тем меньше будет задержка передачи видео, 1го вполне достаточно. Если поток не прерывается, то можно напрямую выводить на монитор с декодера (кстати это тоже занимает время).

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Например специалисты по VR говорят, что задержка от поворота головы до картинки в глаза должна составлять не более единиц миллисекунд, чтобы не было отличий от реальности.

Вот

https://www.oculus.com/blog/building-a-sensor-for-low-latency-vr/?locale=de_DE&_fb_noscript=1

With the new Oculus VR™ sensor, we support sampling rates up to 1000hz, which minimizes the time between the player’s head movement and the game engine receiving the sensor data to roughly 2 milliseconds.

за какие задержки борются разработчики, а там ещё пересчитать сцену надо, плюс другие задержки, бюджета в 8 ms на беспроводную замену HDMI кабеля просто нет, тем более что он и не нужен, как показывают уже существующие разработки с задержками < 1 ms.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

6 minutes ago, lexx said:

В статье 0.25мс это одна строчка пикселей на 1080р 30 fps.

Вы в какой консерватории учились? :)

За 1 секунду передается 1080*30 = 32400 строк.

Поэтому одна строка передается за 1/32400 = 3,1e-5 сек = 0.031 мс.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

11 minutes ago, petrov said:

тем более что он и не нужен, как показывают уже существующие разработки с задержками < 1 ms.

Странный вывод, вы же не сказали, какой там битрейт и при каком качестве. А может быть людям в 2 раза меньше битрейт нужен, а может быть в 10.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...