Согласен, фиксированный размер одного символа всегда лучше. Строки — это не графические данные, например, и жаловаться на удвоение занимаемой памяти строками ну как минимум гоупо. А вообще это выглядит как — а давайте сломаем совместимость, но как бы чуть-чуть, не полностью, чтобы много позже всё же доломать и перейти на UTF-16 в итоге.
Я бы с удовольствием почитал статью по ffmpeg без использования SDL, с многопоточным декодером, синхронизацией A/V, пусть даже без вывода кадра куда либо. Для звука бы использовалась любая подходящая библиотека.
Подозреваю, что производительности они не добавят и будут медленнее своих игровых «близнецов», так, например Quadro P5000 будет гарантированно медленнее GTX1080 из-за меньших частот в бусте. Quadro P4000 медленнее GTX1070 и т.д. А вот разницу между игровым драйвером и studio-драйвером хотелось бы увидеть, если таковая имеется. Это относительно игровых видеокарт nVidia или Pro драйвер для AMD Radeon. В обеих случаях это спец. драйверы для проф. приложений, которые можно поставить на игровые карты. В оправдание AMD и поскольку выяснял уже причины неудовлетворительной производительности данных карт (не в играх), могу сказать, что проблема кроется в крайне плохом поведении энергосберегайки данных карт, он просто не дает карте бустить свои частоты. Драйвер считает, что фпс ограничен программой и нагрузка на карту небольшая (показ видео с обработкой opengl, например, с локом на 30 или 60 фпс) и бустить необязательно. Ну и подозреваю, что в CAD AMD драйвер ведет себя подобным же образом. Выставить максимальные частоты в Radeon Software просто так тоже не получится. Надо использовать утилиту MorePowerTool, которая через реестр исправит проблему и карта будет постоянно работать на максимальной частоте. К сожалению не помню, какую там галочку надо снимать или ставить — тут надо гуглить. У nVidia максимальную производительность можно поставить глобально в драйвере или же отдельно для приложения, но и то это будет не максимальный буст, а предпоследняя или даже пред-предпоследняя ступень буста всего лишь.
А ffmpeg -hwaccel qsv… что говорит? trac.ffmpeg.org/wiki/Hardware/QuickSync Тут вроде как установка и сборка… Если оно еще не на перманентной основе вшито в ffmpeg.
ps При выходе за пределы возможностей аппаратного декодера на 5700xt в данный момент, кстати, падает драйвер. Ну скажем видео 8k не 24 фпс максимум, а 30. А должен сваливаться в софтварный декод. Чего-то там не доделали пока индусы из AMD…
А ведь это даже не серверный процессор, да и ffmpeg не последний… Хотелось бы увидеть результат qsv… А вот у радеона в спеках числится как раз поддержка декодирования 4k AVC на 150fps максимально. И при декодировании этого ролика ASIC загружен на 100%. Диспетчер задач — GPU — Video Encode (ей богу не знаю почему они засунули этот показатель в encode). Но это его потолок. На карточках NV всегда отображается в графике Video Decode.
ps Киношку перезалили вроде как только в 60fps теперь доступна…
Дочитал до i5 8400 и сразу понял вашу проблему. При упоминании HWAccel стоит сразу же оговориться, что оно несёт собой просто тонну проблем и ограничений по входным данным. Размер кадра, битрейт, FPS, уровень и профиль кодека, которым кодировались данные. Все это жёстко ограничивает возможности встроенного в чип ВК аппаратного декодера (ASIC) по количеству поддерживаемых форматов. На днях тестировал декодер 5700xt, где завезли поддержку аж всего и аж в 8k сразу. Во всех тестах r5 3600x оказался быстрее в декодировании, просто в разы. Сегодня, когда zen 2 продается по 5 рублей за кило, лучше даже и не вспоминать про аппаратный декодер.
Он не придумывался для ускорения декодирования видео, он придумывался в качестве очередной энергосберегайки и как замена слабомощным процессорам, а все остальное просто маркетинговый булшит. Да несомненно, в той же 5700xt завезли и аппаратный кодер, но это случилось только «вчера» и ни где никакой поддержки ещё нет, кроме драйвера AMD, который будет кодировать видео с экрана на лету, не напрягая ВК и процессор особо, в ответ на shadow play от зелёных. Вот как-то так пока обстоят дела на сегодняшний и получается, что для этих задач и проще и удобнее использовать процессор. Особенно, когда AMD ударилась в ядра. А у аппаратного декодера всегда есть потолок, например по fps, выше которого он физически не прыгнет. Алсо, когда в последний раз интересовался cuda декодером, он был скорее мертв, чем жив судя по его возможностям. По работе мне надо уметь держать воспроизведение видео любых форматов любого разрешения, в том числе и нестандартных, например 4096х4096, 3600х3600, фишай, а уж 360 видео в равнопромежуточной проекции имеет кучу нестандартных соотношений сторон. Так что к теме имею прямое отношение.
Tecsar CMS устраивает всем, но (возможно проблема китайских регистраторов, конечно) ну прям оооочень долгая загрузка файлов видео по сети, час записи с одной камеры грузится 15 минут. Вторая проблема CMS не позволяет выбрать более 100 (может и менее) файлов для загрузки, то есть если нужен месяц видео отдельно от регистратора — будет очень много ручной работы. Где-то по двое суток придется загружать и применять фильтр каждый раз. Под файлом видео подразумевается час видео и программа сама так делит ролики (00:00 — 00:59, например.)
Я когда это увидел, сразу вспомнил SIMPL от Crestron… Аж глаз задергался от ужаса. А ведь пришлось писать достаточно сложную систему управления на этом с сетью, реализацией telnet протокола, rs232 и прочим блекджеком. Сейчас вот как раз проект, но только на контроллерах Cue — это просто земля и небо. Используется некий XPL2 language. Чем-то похож на паскаль, чем-то на фортран. Нравится мне там одна вещь, простоты реализации которой не хватает, например в Delphi или FPC:
Private Process GetAllRecords(count As Long)
Var i As Long
For i := 0 To count - 1
Avaya1.GetRecordInfo(i)
End For
End Process
А запускается это просто:
StartProcess GetAllRecords(rcount)
дальнейший код выполняется параллельно.
Вообще сейчас вот немного побаловался с PBO и таки удалось догнать сэмулированный через bmp по объему данных кадр якобы 8k yuv420p (7680х1620х32bit) до 110 к/c стиминг+отрисовка… Немного помогло кастомное SSE копирование ещё. Это 9мс уже с отрисовкой, ну 1-2 еще на преобразования, вроде как укладываемся в 16мс. Надо будет покопать в эту сторону…
По поводу «не такой как предыдущий» — имелось ввиду, что когда прилетают кадры видео ролика/карты захвата/веб-камеры и пр. их обрабатывает единственная функция у меня, которая и использует glTexImage2D, которая в свою очередь снимает кучу проблем с выяснением «а какой по размеру был предыдущий кадр (смена видеоролика например), какой формат пикселей был у предыдущего кадра, надо ли пересоздать формат/размер текстуры через glTexImage2D с нулевым пойнтером. К тому же у меня абсолютно всеядный плеер по yuv форматам, коих просто куча, опять же благодаря простоте использования glTexImage2D. Использую ffmpeg разумеется и получаю непосредственно распакованный кадр в yuv формате любом (конвертирование шейдером). Пробовал использовать glTexSubImage2D, но это надо сохранять данные каждого полученного кадра и каждый последующий сравнивать с предыдущим по формату/размеру и т.д., чтобы в случае чего пересоздать текстуру через glTexImage2D с нулевым пойнтером.
По поводу PBO — видел, пробовал. В моем случае ускоряет ровно в 2 раза при загрузке кадра 8k (7680x4320), но все упирается в софтовое копирование данных в маппированную память GPU.
По ссылке — это void updatePixels(GLubyte* dst, int size), т.е. мне все равно надо вручную копировать полученный из ffmpeg кадр куда-то, а в моем случае еще и до 3х раз при наличии 3х битовых полей у yuv кадра. В итоге разница с простецким glTexImage2D даже хоть и 2 раза, но 8k 60fps не тянет ни то ни это… максимум 30.
зы тестировалось на gtx1080 и Vega64
https://www.nvidia.ru/object/io_1236954052122.html
Ну и простите, не удержался —
trac.ffmpeg.org/wiki/Hardware/QuickSync Тут вроде как установка и сборка… Если оно еще не на перманентной основе вшито в ffmpeg.
ps При выходе за пределы возможностей аппаратного декодера на 5700xt в данный момент, кстати, падает драйвер. Ну скажем видео 8k не 24 фпс максимум, а 30. А должен сваливаться в софтварный декод. Чего-то там не доделали пока индусы из AMD…
Video: h264 (High) (avc1 / 0x31637661), yuv420p, 3840x2160 [SAR 1:1 DAR 16:9], 18005 kb/s, 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc (default)
R5 3600x:
ffmpeg -threads auto -i "f:\Films\COSTA RICA IN 4K 30fps (ULTRA HD) w Freefly Movi.mp4" -f null - -benchmark
frame= 5111 fps=482 q=-0.0 size=N/A time=00:02:50.94 bitrate=N/A speed=16.1x
Radeon 5700xt:
ffmpeg -hwaccel dxva2 -threads 1 -i "f:\Films\COSTA RICA IN 4K 30fps (ULTRA HD) w Freefly Movi.mp4" -f null - -benchmark
frame= 1267 fps=148 q=-0.0 size=N/A time=00:00:42.28 bitrate=N/A speed=4.94x
А ведь это даже не серверный процессор, да и ffmpeg не последний… Хотелось бы увидеть результат qsv… А вот у радеона в спеках числится как раз поддержка декодирования 4k AVC на 150fps максимально. И при декодировании этого ролика ASIC загружен на 100%. Диспетчер задач — GPU — Video Encode (ей богу не знаю почему они засунули этот показатель в encode). Но это его потолок. На карточках NV всегда отображается в графике Video Decode.
ps Киношку перезалили вроде как только в 60fps теперь доступна…
Он не придумывался для ускорения декодирования видео, он придумывался в качестве очередной энергосберегайки и как замена слабомощным процессорам, а все остальное просто маркетинговый булшит. Да несомненно, в той же 5700xt завезли и аппаратный кодер, но это случилось только «вчера» и ни где никакой поддержки ещё нет, кроме драйвера AMD, который будет кодировать видео с экрана на лету, не напрягая ВК и процессор особо, в ответ на shadow play от зелёных. Вот как-то так пока обстоят дела на сегодняшний и получается, что для этих задач и проще и удобнее использовать процессор. Особенно, когда AMD ударилась в ядра. А у аппаратного декодера всегда есть потолок, например по fps, выше которого он физически не прыгнет. Алсо, когда в последний раз интересовался cuda декодером, он был скорее мертв, чем жив судя по его возможностям. По работе мне надо уметь держать воспроизведение видео любых форматов любого разрешения, в том числе и нестандартных, например 4096х4096, 3600х3600, фишай, а уж 360 видео в равнопромежуточной проекции имеет кучу нестандартных соотношений сторон. Так что к теме имею прямое отношение.
Пардон, не прочитал комментарий выше…
… потому что — лень.
Private Process GetAllRecords(count As Long)Var i As Long
For i := 0 To count - 1
Avaya1.GetRecordInfo(i)
End For
End Process
А запускается это просто:
StartProcess GetAllRecords(rcount)
дальнейший код выполняется параллельно.
Простите, не удержался…
По поводу PBO — видел, пробовал. В моем случае ускоряет ровно в 2 раза при загрузке кадра 8k (7680x4320), но все упирается в софтовое копирование данных в маппированную память GPU.
По ссылке — это void updatePixels(GLubyte* dst, int size), т.е. мне все равно надо вручную копировать полученный из ffmpeg кадр куда-то, а в моем случае еще и до 3х раз при наличии 3х битовых полей у yuv кадра. В итоге разница с простецким glTexImage2D даже хоть и 2 раза, но 8k 60fps не тянет ни то ни это… максимум 30.
зы тестировалось на gtx1080 и Vega64