1)По сети фрагментами приходят сжатые H.264 данные. (те кто не знаком с H.264 можно представить что это просто сжатые данные)
2)Фрагментация не коррелирует с прикладным форматом. То есть нарезка может быть в любом месте.
3)Мой декодер H.264 читает данные порциями в соотвествии с этим форматом.

Требуется реализаци функционала READ и SEEK FORWARD по этим данным. Считается что после READ данные можно освобождать.
Требуется избежать копирования.

Получение/обработка данных выглядит предположительно так:

1) Ставится буффер размером 100 чунков на получение. Один чунк предположим равен грануляции выделения памяти.
2) Происходит получение 20К данных.
3) Буффер освобождается/реаллоцируется без копирования до размера полученных данных.
4) Буффер добавляется в очередь
5) Разблокируется ждущая до этого функция чтения декодера.
6) После чтения из очереди буффера освобождаются.

Как реализовать в лоб понятно... Но вот чего-то готового найти не смог.

Как это лучше сделать на базе чего-то готового или как переделать процесс обработки потока?

Здравствуйте, imh0, Вы писали:

I>Требуется избежать копирования.
Избежать копирование где, из очереди при передачи в декодер?

I>Получение/обработка данных выглядит предположительно так:

I>1) Ставится буффер размером 100 чунков на получение. Один чунк предположим равен грануляции выделения памяти.
Что такое грануляция выделенной памяти? В window грануляция это памяти это термин применяемый только в I/O и она равна 64 Кб. Может быть вы имеете в виду размер страницы 4 Кб ?

I>2) Происходит получение 20К данных.
Зачем тогда информация про 100 чанков? 20К маловато будет, h264 nalu запросто может быть 150Кб или болше.

I>3) Буффер освобождается/реаллоцируется без копирования до размера полученных данных.
I>4) Буффер добавляется в очередь
I>5) Разблокируется ждущая до этого функция чтения декодера.
I>6) После чтения из очереди буффера освобождаются.

I>Как реализовать в лоб понятно... Но вот чего-то готового найти не смог.
Смотрите: у вас в конвейере как минимум два узких горлышка. Первое — это ожидание I/O на входе. Если это риалтаймовый поток, то для процессора это вечность. Второе — это декодер. Мне сложно представить что бы декодер работал быстрее чем любой из разумных способов поставлять для него сжатые семплы. Посмотрите реализацию ffmpeg, там люди не бояться использовать копирование и при этом все работает довольно быстро. Обычно все пляски с оптимизацией копирования связаны с раскомпрессированными данными, но это не ваш случай, как я понял.

I>Как это лучше сделать на базе чего-то готового или как переделать процесс обработки потока?
Мне кажется что копирование nalu h.264 не является узким местом и вы не ту проблему решаете. Исключение может быть если мы не декодируем h.264 поток и строим какой-то сильно производительный маршрутизатор, где скорость может оказать влияние. Не понятно что вас не устраивает в вашем текущем методе?

Здравствуйте, Videoman, Вы писали:

I>>1) Ставится буффер размером 100 чунков на получение. Один чунк предположим равен грануляции выделения памяти.
V>Что такое грануляция выделенной памяти? В window грануляция это памяти это термин применяемый только в I/O и она равна 64 Кб. Может быть вы имеете в виду размер страницы 4 Кб ?

Я тут имел ввиду, что во избежании фрагментации кучи при реаллокации (изменения размера выделенного блока без копирования), память выделяется всегда кратно какой то величине.
Ну это скорее из области "дуть на воду", так как современные аллокаторы сами об этом заботятся. То есть можно забить))

I>>Как это лучше сделать на базе чего-то готового или как переделать процесс обработки потока?
V>Мне кажется что копирование nalu h.264 не является узким местом и вы не ту проблему решаете. Исключение может быть если мы не декодируем h.264 поток и строим какой-то сильно производительный маршрутизатор, где скорость может оказать влияние. Не понятно что вас не устраивает в вашем текущем методе?

Главная "проблема" которую я пытаюсь обойти, это то что в процессе доставки nalu они могут быть перефрагментированы... То есть может быть где-то на маршруте может произойти нарезка с другой фрагментацией.

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

==
Большое спасибо за ответ, я пока сделал "на коленке", — считаю что проблему возможной переренарезки фрагментов буду решать потом.

Здравствуйте, imh0, Вы писали:

I>Здравствуйте, Videoman, Вы писали:

I>Главная "проблема" которую я пытаюсь обойти, это то что в процессе доставки nalu они могут быть перефрагментированы... То есть может быть где-то на маршруте может произойти нарезка с другой фрагментацией.

Не очень понятно что за проблема.

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

На самом деле копирование даже 200-300mbps стримов обычно не сильно влияет на производительность системы, вот копирование RAW данных после декодера могут создавать существенные проблемы, для примера 4K YUV 422 10бит 60fps это уже ~16Gbit/s. Мы в своем фреймворке используем рефернсные буфера для входных стримов (те если данные не модифицируются компонентом, то передаются как референс), но это было сделано только для унификации интерфейсов, и особой выгоды не дают. те на профайлере мы не видим этого копирования в топе функций.