Message #269 VideoStreamInformation never receive

[SilvainIADYS]

Message #269 VideoStreamInformation never receive

[benbarkay]

If you could provide some packet bytes then that would be very helpful :)

[SilvainIADYS]

Yes, of course. I using now 1.1.4 version.

When I use MavlinkPacketReader :
I/System.out: MavlinkPacket{versionMarker=253, incompatibleFlags=0, compatibleFlags=0, sequence=27, systemId=1, componentId=100, messageId=269, payload=[0, 0, 32, 65, 0, -32, -91, 1, 1, 0, -48, 2, -32, 1, 0, 0, 0, 0, 1, 1, 2, 99, 97, 109, 101, 114, 97, 32, 102, 114, 111, 110, 116, 97, 108, 101], checksum=27381, signature=[]}

When I break down the message, I see that there is not enough byte to encode the name and the uri (even with data truncation). But I do not know if it's important.

Here is the C code to send the message :
mavlink_message_t msgRep;
char name[32] = "camera frontale";
char uri[160] = "";
mavlink_msg_video_stream_information_pack(paramIdSysMavlink, paramIdCompMavlink, &msgRep, 1, 1, VIDEO_STREAM_TYPE_TCP_MPEG, VIDEO_STREAM_STATUS_FLAGS_RUNNING, FRAMERATE_MAX, 720, 480, (720 * 480 * FRAMERATE_MAX * 8), 0, 0, name, uri);

Thanks for your help

[SilvainIADYS]

Hi,
The message was shorter because Mavlink cut the zeros at the end and as uri (last field) was empty, it was not reconciled.
Any way, even with full data, the message is not received by MavlinkMessage.

Here is the log :
I/System.out: MavlinkPacket{versionMarker=253, incompatibleFlags=0, compatibleFlags=0, sequence=23, systemId=1, componentId=100, messageId=269, payload=[0, 0, 32, 65, 0, -32, -91, 1, 1, 0, -48, 2, -32, 1, 0, 0, 0, 0, 1, 1, 2, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97], checksum=27841, signature=[]}

[benbarkay]

I'll take a closer look at this over the weekend, however if what you say is true and there isn't enough space in the payload to contain the full message, then it's likely that what ends up happening is that the packet is dropped for invalid checksum -- Sender generates checksum based on full data, and receiver generates a mismatching one based on partial data.

Do you receive the message when encoding a shorter url/name that does fit a packet?

[SilvainIADYS]

There is enough place in the payload and I get the message in full.
What I wanted to say is that mavlink removes the zeros at the end of the payload (see https://mavlink.io/en/guide/serialization.html#payload_truncation) and therefore the uri when it is empty (filled with zero).

In both cases, the packet is unrecognized.

[benbarkay]

I understand. It would help significantly if you could record some bytes which contain the message into a file and upload it here, this way I'd have a quick way of reproducing the exact issue once I'm on it

[SilvainIADYS]

Hi,
Here is the file you asked.
There are Heartbeat of the main component ID1, camera component ID100 and the 269 message.
trame.txt

[benbarkay]

See my newest comments

@SilvainIADYS it appears to me that mavlink_msg_video_stream_information_pack has no such field name, did you add it yourself?

When I've used the following code to create message bytes:

JNIEXPORT jbyteArray JNICALL
Java_io_dronefleet_mavlink_testtool_CLibraryTestTool_createVideoStreamInformationBytes(
        JNIEnv *env,
        jobject obj) {
    char buf[280];

    mavlink_message_t message;
    uint8_t stream_id = 1;
    uint8_t count = 1;
    uint16_t flags = VIDEO_STREAM_STATUS_FLAGS_RUNNING;
    float framerate = 30;
    uint16_t resolution_h = 720;
    uint16_t resolution_v = 480;
    uint32_t bitrate = resolution_h*resolution_v*framerate*8;
    uint16_t rotation = 0;
    uint16_t hfov = 0;
    const char *uri = "http://test.com/test";


    int len = mavlink_msg_video_stream_information_pack(255, 0, &message,
                stream_id, count, flags, framerate, resolution_h, resolution_v,
                bitrate, rotation, hfov, uri);
    mavlink_msg_to_send_buffer(buf, &message);

    jbyteArray array = (*env)->NewByteArray(env, len);
    (*env)->SetByteArrayRegion (env, array, 0, len, (jbyte *)buf);
    return array;
}

And ran the following:

@Test
public void test() throws IOException {
    byte[] b = CLibraryTestTool.createVideoStreamInformationBytes();
    ByteArrayInputStream in = new ByteArrayInputStream(b);
    ByteArrayOutputStream out = new ByteArrayOutputStream();

    MavlinkMessage message = MavlinkConnection.create(in, out).next();
    System.out.println(message);
}

I got this output:

MavlinkMessage{packet=MavlinkPacket{versionMarker=253, incompatibleFlags=0, compatibleFlags=0, sequence=0, systemId=255, componentId=0, messageId=269, payload=[0, 0, -16, 65, 0, -96, -15, 4, 1, 0, -48, 2, -32, 1, 0, 0, 0, 0, 1, 1, 104, 116, 116, 112, 58, 47, 47, 116, 101, 115, 116, 46, 99, 111, 109, 47, 116, 101, 115, 116, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 50, 9, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 124, 31, 0, 0, 0, 0, 0, 0, 2, 0, 0, 0, -119, 12, 0, 0, 0, 0, 0, 0, 4, 0, 0, 0, -19, 14, 3, 12, 13, 0, 0, 0, 5, 0, 0, 0, -39, 28, 1, 0, 0, 0, 0, 0, 6, 0, 0, 0, 104, 3, 0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 119, 32, 0, 0, 0, 0, 0, 0, 11, 0, 0, 0, 89, 6, 1, 4, 0, 0, 0, 0, 20, 0, 0, 0, -42, 20, 3, 2, 3, 0, 0, 0, 21, 0, 0, 0, -97, 2, 3, 0, 1, 0, 0, 0, 22, 0, 0, 0, -36, 25], checksum=46011, signature=[]}, payload=VideoStreamInformation{streamId=1, count=1, flags=EnumValue{value=1, entry=VIDEO_STREAM_STATUS_FLAGS_RUNNING}, framerate=30.0, resolutionH=720, resolutionV=480, bitrate=82944000, rotation=0, hfov=0, uri=http://test.com/test}}

When reading from the text file that you've sent me, the messages were being dropped because they did not pass CRC validation. That's expected if you've modified the dialect XML files and generated your own customized C library.

If you're making a specialized product and don't care for the GCS code to support other autopilots then you can clone the repository and generate Java code for your customized dialect XMLs.

[benbarkay]

@SilvainIADYS You can also mark your own fields as extensions, in which case these would be added at the end of the packet and not create CRC discrepancies as they wouldn't change the message's CRC extra.

Although I'd assume that if you go through the trouble of adding these, you'd like them available to the GCS...

[benbarkay]

Looks like VideoStreamInformation has been modified 21 days ago at commit:
mavlink/mavlink@84d1bcb#diff-ceacc1e2390186650146a45be8fcb691

Will make a release with updated dialects shortly :)
My bad with the previous two responses.

[benbarkay]

Released 1.1.5, should fix this for you. Do note though that VideoStreamInformation is a work in progress, a future release with updated message definitions may cause a similar discrepancy to happen again.

[SilvainIADYS]

Thanks for your help. I will try with the 1.1.5 release.
I keep in mind that this message is not definitive.

[benbarkay]

Has this been resolved?

[SilvainIADYS]

Yes, it's perfect.
Thanks for your help