Приветствую.
Опять продолжение темы Запись сырого h264
Теоретический подсчет показал, что в сравнении с raw записью 1920х1080 MJPEG создающую нагрузку на носитель где то 1.2 Мб/c при 5 фпс, такая же запись H264 при 30 фпс создает поток где то 0.6 Мб/c, т.е. в принципе уже проверенную пропускную способность по записи укладываюсь, а вот с онлайн стримом вопрос.
Абсолютно точно придется пропускать кадры. Если для мжпег удалось сделать это очень равномерно, т.к. из очереди std::deque всегда брался для пересжатия из мжпег в х264 только последний кадр, то в случае с h264 нужно занусуть видео поток в канал где то до 2мбит/c, т.е. декодирование->масштабирование в 2-2.5 раза->сжатие. Все это делается на слабенькой arm пока без доступа к ядру гпу.
Первое что приходит в голову это подряд пересжимать кадры и сбрасывать очередь каждый раз при поступлении I кадра - да камера отдает I кадры каждую секунды и еще 29 P кадров, расстояние не большое, но «рывок» в конце каждой секунды все равно хоть как будет и скорее всего придется отбросить 2/3 кадров (по аналогии с мжпег пересжатием в х264).
Буду благодарен любой идее )
