Запись сырого h264

А надо именно tcp? Просто то что ты описываешь смахивает на hls

Пока tcp использую просто как надёжный вариант передачи записанного архива между двумя своими софтинами на основе ffmpeg библиотек

Вопрос больше не в нем, а в каком формате не ресурсно записать локально, чтоб потом опять же не ресурсно было кинуть через интернет (в идеале не используя никаких прокси серверов как http для hls) ???

в отличии от жпега представление внутренней структуры кадров на Хабре как то не нашлось

h264 нарезает данные на Network Abstraction Layer units(NALu). Посмотреть как их парсить можно в коде gstreamer плагина h264parse: https://github.com/GStreamer/gst-plugins-bad/blob/master/gst-libs/gst/codecparsers/gsth264parser.c

gstreamer очень хорош для работы с видео: преобразования, упаковки в любые контейнеры, передачи по сети, записи в файл. Утилита gst-launch позволяет задавать цепочки обработки видео в командой строке. gstreamer хорошо работает на слабом железе.

ффмпег попроще и побыстрей, тем более по слухам гстример его тоже использует)

Речь не про то как отдельные блоки найти, а как в них безболезненно дописать свои данные

Вот что я имею ввиду когда говорю про описание внутренней структуры блоков jpg https://habr.com/ru/articles/102521/

Может, Fragmented MP4 подойдёт?

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

ффмпег попроще

Нет.

по слухам гстример его тоже использует)

Нет.

Не, если уже буду засовывать в мп4, то уже без всяких фрагментов, речь пока можно ли что то сделать с сырым кадром h264

Хотя надо ещё почитать про принцип его работы, может на что то натолкнет

Ну на все ответы как бы - да https://gstreamer.freedesktop.org/modules/gst-ffmpeg.html

Ффмпег может писать в контейнер кусками и сразу в м3у (hls да) - в м3у можно писать свои меточки в комментах если надо Данные между блоками не теряются но воспроизводящий конец должен уметь переключать блоки кадр-в-кадр На чахлом Арме это все работает без проблем ибо математики нуль

https://gstreamer.freedesktop.org/modules/gst-ffmpeg.html

Это ссылка на протухший плагин для ветки 0.1. Плагин, которые использует библиотеки libavcodec, libavformat и т.д. называется gst-libav. Сама утилита ffmpeg не используется.

Ну на все ответы как бы

Нет. Для gstreamer тебе в большинстве случаев не нужно будет писать код. Задачи можно решать составлением конвейеров в консольной утилите. Если делать через libav, то придётся обмазываться сишкой по самые уши. Там банальной синхронизации видео со звуком нет из коробки.

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

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

Либо я не понял в чём сцуть m3u и надо ещё почитать

Как бы выглядело в идеале - libav ффмпега отдает мне демультиплексированеый кадр h264, без декодирования по его hex содержимому определяю I или P кадр, если I пишу внутри кадра мои метки в предназначенное для этого место, потом для «воспроизведения» в сеть простое чтение кольца кадров с носителя.

Во всей этой канители не понятно даже, что после демуксера ффмпега содержит AVPacket, является ли это вообще кадром для кодека х264, может там набор каких то блоков, а кадр только после декодера можно получить

аж слезу вызвало. Все те проблемы, с которыми я в 2010-м году сталкивался, но теперь хотя бы у тебя быстро закончилась херня с mjpeg-ом.

H264 нал-юниты в первом байте маркируются типом. Тебе пока нужен IDR или SINGLE. Потом познаешь боль от SEI.

А вот у Single ещё иногда стоит прочитать slice type, который иногда сигнализирует о том, что проигрывать можно и отсюда.

Но для начала тебе надо будет распаковать FUA пакетизацию (вряд ли ты увидишь FUB или STAPA)

В помощь тебе документ T-REC-H.264-201304-I!!PDF-E (можно и посвежей, но там мало что менялось).

Спасибище! Буду читать аб том.

Мжпег не закончился, он просто сделан и уже успешно работает )

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

Но это использование сугубо опциональное - можно использовать родные кодеки, а можно из ffmpeg.

да у него вся архитектура на опциональности построена, но раз используют, значит «это жжж неспроста» (с)

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

Поясню - у тебя два пути - либо отдать разбор и паковку сторонней утилите (ффмпег один из вариантов) и не прибивать свою мошонку гвоздем к н264, либо скроить чуток операций и разбирать н264 самому и переодически огребать горя потому что тот-же ффпмег эти «лишние операции» делает не просто так.
Нюанс (с) - 264му активно педалируется замена в виде 265

Либо я не понял в чём сцуть m3u и надо ещё почитать

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

он уже научился не падать от HDR (с 10 битами на канал) видео?

У меня свой плейлист создаётся при первом запуске железки через перечитывание всего носителя, 512гб карта от нескольких минут до наверное часа читается в худшем случае

Надо все таки мне посмотреть hex структуру, может там не все так сложно и аналогично jpg можно сделать.

Да понимаю что это ограничение закладываю, но проблема ограниченных ресурсов тому виной.