Как правильно считать FragmentOffset для RTP? Опции

[BSACPLD]

Я тут разбирался с RTP для JPEG и обнаружил несовпадение при вычислении FragmentOffset у разных видеокамер.
У D-Link DCS-2132L камеры FragmentOffset считается по полю payload, а у Waveserver 3554 по payload+dqt_header+dqt.
Во втором пакете у DCS-2132L FragmentOffset = 1292, а в третьем FragmentOffset = 1424, т.е. длина поля dqt не учитывается (1424-1292 = 132 - как раз длина поля dqt).
У Waveserver 3554 FragmentOffset всегда равен 1400, т.е. он учитывают ещё и длину dqt.
В общем вопрос как правильно?

[novartis]

Fragment Offset - это номер первого байта данных в текущем пакете относительно всего jpeg кадра.
К примеру, у вас jpeg кадр 6000 байт. Он разобьется на 5 udp/rtp пакетов.
В первом пакете fragment offset будет 0.
Во втором пакете fragment offset будет 1260.
В третьем - 2652.
В четвертом - 4044.
В пятом - 5436.
(Привел цифры из лога wireshark для моей собственной программы).

В первом пакете payload 1260 байт, также в первом пакете есть таблица квантования, но она получается не учитывается в fragment offset, так как у второго пакете fragment offset как раз в размер payload 1260.

Во втором пакете таблицы квантования нет. Payload равен 1392. Как раз в третьем пакете и получается 1260+1392=2652.
И так далее.


Еще добавлю, в rtp пакеты засовывается не весь jpeg кадр, в payload укладываются только полезные данные из jpeg. Заголовок выкидывается, таблица квантования как видите упаковывается в первый пакет вне payload.
Но вы это проверьте, насчет заголовка, а то может наврал.

[BSACPLD]

Взял код из RFC2435.
Скомпилировал и посмотрел, что он выдаёт.
Итог: D-Link соответствут RFC2435 и тому, что Вы написали, а Waveserver - нет.

P.S.
Насчёт заголовка Вы всё правильно сказали.