Reading gstreamer udp-stream from .blf-file fails
Reading a .blf file that includes udp-packets send by gstreamer aborts with ObjectHeaderBase being nullptr.
Same file can be read by vector CANalizer without problems. Other udp packets / ethernet frames are working fine. No difference if other data is present or not (e.g. CAN-Channels).
Attached you will find a .blf log containing the aforementioned udp-stream only.
The issue was reproduces with Versions 2.1.5 and 2.1.6
Comments (7)
-
repo owner -
Hi Tobias, thanks for the quick reply.
My environment is
GCC 7.4.0 on Ubuntu 18.04 with the flags -O3 -DNDEBUG
The file is part of a catkin compilation (ROS1-Melodic) that is triggered with the following command:
catkin_make --directory ${workspaceFolder} -DCMAKE_BUILD_TYPE=Release
Taking a look at the example (Parser.cpp) with the file I send you it does look like this.
FileStatistics:
statisticsSize: 0x90
applicationId: 84
applicationVersion: 245.61.0
apiVersion: 1.1.10.0
fileSize: 27366520 (0x1a19478)
uncompressedFileSize: 29014245 (0x1bab8e5)
objectCount: 20200
objectsRead: 96
measurementStartTime: 2019-10-14 1 18:11:22.563
lastObjectTime: 2019-10-14 1 18:11:52.777
fileSizeWithoutUnknown115: 0x1a192e6
…
ObjectSize=536 doesn't match calculatedObjectSize()=56
End of file.
uncompressedFileSize: 29014245
objectCount: 20200
I guess the objectsRead should be equal to objectCount?
Taking a look at more relevant logs, that I’m not allowed to share, it does look more grim.
FileStatistics:
statisticsSize: 0x90
applicationId: 84
applicationVersion: 245.61.0
apiVersion: 4.6.5.17
fileSize: 2049629000 (0x7a2adb48)
uncompressedFileSize: 10024578740 (0x25582eeb4)
objectCount: 25040292
objectsRead: 0
measurementStartTime: 2019-10-24 4 13:29:30.0
lastObjectTime: 2019-10-24 4 13:38:4.885
fileSizeWithoutUnknown115: 0x7a2ab282
…
ObjectSize=120 doesn't match calculatedObjectSize()=64
End of file.
uncompressedFileSize: 917872
objectCount: 310
I hope I provided all information necessary.
Thanks for your effort and time in this investigation.
-
repo owner Hi Christof,
I can reproduce the issue now. However the data looks different here:
FileStatistics: statisticsSize: 0x90 applicationId: 84 applicationVersion: 245.61.0 apiVersion: 1.1.10.0 fileSize: 27366520 (0x1a19478) uncompressedFileSize: 29014245 (0x1bab8e5) objectCount: 20200 objectsRead: 96 measurementStartTime: 2019-10-14 1 18:11:22.563 lastObjectTime: 2019-10-14 1 18:11:52.777 fileSizeWithoutUnknown115: 0x1a192e6 ... 30214581000 ns: Unknown115: res[0]=0x30113e80 res[1]=0x000001f0 res[2]=0x3011436a res[3]=0x01e801f0 res[4]=0x00180008 res[5]=0x000003e8 ObjectSize=536 doesn't match calculatedObjectSize()=56 End of file. uncompressedFileSize: 29014245 objectCount: 20200
So it seems that only the trailing message “Unknown115” has a different format. I’ll check and fix it.
Can you try with the latest version if your objectCount also totals up to 20200?
Bye
Tobias
-
repo owner Hi Christof,
I did a commit in this branch: https://bitbucket.org/tobylorenz/vector_blf/branch/issue-18.
Instead of showing the message “
ObjectSize=120 doesn't match calculatedObjectSize()=64
” it just consums the available data. The parser has been changed as well to show what’s inside this message.Unknown115 is anyway the last message, so there isn’t anything important missing, if the library/parser stops here.
Bye
Tobias
-
repo owner Hi,
I merged issue-18 branch into master and released v2.2.0.
I assume this issue is solved now.
Bye Tobias
-
repo owner - changed status to resolved
-
repo owner -
assigned issue to
-
assigned issue to
- Log in to comment
Hello,
I checked the BLF now in multiple environments and couldn’t reproduce the issue. The vector-blf-parser example successfully decodes 19468 objects of type EthernetFrameEx.
What environment do you use the library in? What compiler and ~options?
Bye Tobias