Подключить две IP камеры.

У вас полный бардак в приложении. Копайте в libavformat. libavformat_open_input(ctx, «rtsp://...», ...)

Прошу прощения. Вчера был день рождения, вот и написал ерунду.
Есть самопальные камеры на STM32, которые подключаются через Ethernet. Контроллер постоянно опрашивает матрицу и передает поученные данные (с помощью Ethernet-контроллера). Вот эти данные мне и нужно читать. Никакого rtsp там нет.

По-видимому Вы ошиблись в связке SIGNAL-SLOT, возможно завели на один слот сигналы от обеих камер.

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

С одной из камер приходит неполный кадр

Вот Вам и причина, от Qt это никак не зависит.

Вот я и хочу понять, почему он приходит неполным. Может я что-то (скорее всего так и есть) делаю не так. По отдельности они обе работают нормально. Меня больше интересует, не может ли это быть из-за того, что они раотают на одном порту?

cast Eddy_Em же. он по STM шарит

не может ли это быть из-за того, что они раотают на одном порту

Они отдают с одного порта или подключаются к одному порту? В любом случае это не должно вызывать проблем.
Кстати, какой протокол используется для передачи данных, tcp или udp, возможно у Вас проблема в этой части?

Предположу, что неполный кадр, потому что вы надеетесь считать из сокета все за один раз. В случае TCP надо в цикле читать данные пока не будет получено необходимое количество или соединение не будет закрыто.

tcpdump или wireshark уже расчехлял?

Ни с tcpdump ни с wireshark дел раньше не имел. Сижу разбираюсь. Теперь выяснилось, что кадры могут не доходить и от двух камер сразу. Появилась (возможно глупая) догадка. Камеры подключены через свич. Может ли быть такое, что ширины свича не хватает? Камеры шлют данные непрерывно. Получается каждая дает чуть больше 50 МБит/с. А свич на 100.

Да так и делаю. Есть буфер. В него читаю по сигналу от сокета (то есть добавляю к тому, что уже было считано). Когда вижу разделитель, выгребаю из буфера все до разделителя (ну и его тоже). То, что пришло после разделителя остается в буфере до получения следующего разделителя.

STM здесь вряд ли как-то влияет. Когда одна камера, то все в порядке. Здесь проблема в моем слабом понимании сетей и их работы.

Получается каждая дает чуть больше 50 МБит/с

50 Мбит/сек видеопотока? У тебя там 4К video в 60фпс что-ли? Или RAW?

RAW

У нас, когда работали с RAW, была аналогичная проблема из за сетевой, поток доходил до 1Гбит/с.

Так что, такое может быть из-за ширины канала, и моя догадка не так уж и глупа?

Скорее из за приёмного буфера карточки, попробуйте поиграться с ним и, возможно, поможет установка jumbo frame.

Вам, батенька, гигабит нужен

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

Дык, на материнской плате карта и так на гигабит. Сомневаюсь, что поднятие mtu здесь поможет. Там по дороге еще и свич стоит. А вот с ним вряд ли получится что-то сделать. Попробую поставить вторую сетевую.

Материнская плата не самая плохая на компьютере. С гигабитом. А вот про третью камеру — в точку. Начальство уже три хочет, хотя я еще с двумя ладу не могу дать.

Дык, на материнской плате карта и так на гигабит

У нас была заметна разница между D-Link и Intel, обе дискретные.

Здесь Intel стоит (интегрированная).

blocking sockets?

No.

Да, дело было в ширине канала. С гигабитным свичем все работает.