ffmpeg + RTSP ограничение длительности где?

https://en.wikipedia.org/wiki/Presentation_timestamp

Presentation time stamps have a resolution of 90kHz, suitable for the presentation synchronization task

это хорошо, но причина ограничения и как его преодолеть там нет

причина ограничения

$ bc -ql
(13*3600+15*60)*90000
4293000000

Знакомое число, не правда ли? Оно практически совпадает с максимальным значением 32-битного uint’а, после которого он переполняется

как его преодолеть

Учитывать в коде плеера возможность переполнения счетчика

да вы абсолютно правы про число и тоже про это думал, но я же везде указал uint64_t, а это переполнение происходит внутри сервера, при этом pts/dts в либах ffmpeg это int64_t

https://ffmpeg.org/doxygen/5.0/structAVPacket.html

похоже где то неявное приведение типа происходит в моем коде…

В PES-пакете длина поля PTS по дефолту 33 бита (но может быть увеличена флагами). Стандарт DVD ограничивает PES 32 битами. Возможно, ответ где-то здесь.

да откуда вы из описания взяли MPEG-TS то?

У TS речь шла про RTSP, где на таймкод уходит 32 бита, а таймкод идет обычно в тех же 90 кгц.

В mpegts 33 бита хватает на 26 часов, а тут как раз на 13 часов.

И проблема в том, что его код не умеет читать RTCP SR с NTP временем и преобразовывать таймстемпы в абсолютное время.

В шараге, где я работал, никакого RTCP не использовали, все читалось из TS-пакетов. Условный рефлекс сработал.

как же так он уходит 32 бита, если структура описывающая пакет для ts 64 битна???

зы. дебажу 13 часов, надеюсь все таки проблема с преобразованием типа…

а что такое вообще SR ?

думал RTCP просто для управления полосой и для онлайн трансляций не используется

зы: SR - Sender Report - отчёт отправителя по отправленным медиа-пакетам RTP

понятней не стало…

https://www.freesoft.org/CIE/RFC/1889/19.htm

RTP timestamp: 32 bits Corresponds to the same time as the NTP timestamp (above), but in the same units and with the same random offset as the RTP timestamps in data packets. This correspondence may be used for intra- and inter-media synchronization for sources whose NTP timestamps are synchronized, and may be used by media- independent receivers to estimate the nominal RTP clock frequency. Note that in most cases this timestamp will not be equal to the RTP timestamp in any adjacent data packet. Rather, it is calculated from the corresponding NTP timestamp using the relationship between the RTP timestamp counter and real time as maintained by periodically checking the wallclock time at a sampling instant.

это ужасно!!! а что делать то???

частоту понизить!?

да в чём проблема то?

добавьте в свой код обработки PTS соотвествующую проверку

Проверю я что большое птс, делать то потом что? По новой стрим начинать?

Например, можно хранить у себя 64-битную переменную и продолжать ее обновлять

в RTP вообще нет PTS/DTS, там есть только таймкод. И некоторые пытаются в него класть не DTS, а PTS чтобы потом из структуры H264 восстановить DTS.

Там бфреймы больно передавать.

вопщим ошибка в неявном приведении типа не подтвердилась, птс/дтс растут в перекодировщике, а переполняются только на сервере, представляющий из себя тот же ффмпег

предложили еще вот такую штуку попробовать http://ffmpeg.org/pipermail/libav-user/2023-February/013291.html

последний совет помог, сутки стрима прошли, интересно насколько 64 битной метки времени хватит )

все работает хорошо ровно 13 часов и 15 минут, потом временные метки pts/dts на сервере вдруг не с того не с сего начинают приходить с нуля, следовательно онлайн видео ложится,

Нет, не следовательно - переполнение меток таймстампа никак не должно приводить к падениию видео. По стандарту RTSP, как правильно писали выше, используется 32-битная переменная и таким образом таймстамп обнуляется.

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

Скорее всего, это происходит от непонимания принципов работы RTSP. Что, следует заметить, не ваша вина, т.к. эти принципы разбросаны по 10-кам документам и нигде в суммарном виде не зафиксированы.

А именно - таймстамп, который вы получаете - это вообще не время. Это метка которая используется для синхронизации видео с аудио (и другими потоками). И сам по себе больше ни для чего. Ещё раз: один таймстамп нельзя использовать ни для каких других целей, кроме синхронизации v/a и потому 32битной переменной тут достаточно.

Если вы хотите получать именно время с камеры/другого источника видеопотока вам нужно использовать связку rtсp + timestamp. В rtcp пакетах время от времени приходит timestamp и соответствующий ему UTC.

) никакого время с камеры я не получаю и временные метки только для синхронизации и использую, а как вы выразились баг вообще не в моем коде - так работает ффмпег, где переменная под метку 64битна

Но в том числе по вашему ответу возник другой вопрос - никто не запрещает послать просто RTP поток ибо он UDP через NATы, без всяких согласований по TCP протоколами вроде RTSP/RTCP (проверял отправляя в VLC), раз такое возможно, следовательно должны быть либо проще способы чем использовать что то ещё для банальной синхронизации (хотя в моем случае это больше корректное распределение кадров, тк звука пока нет), либо метка может быть 64битна (кстати по ссылке выше 64битные метки в ффмпег у меня заработали)