[BSACPLD 14]

Я тут разбирался с 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 0]

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 14]

Взял код из RFC2435.

Скомпилировал и посмотрел, что он выдаёт.

Итог: D-Link соответствут RFC2435 и тому, что Вы написали, а Waveserver - нет.

 

P.S.

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