Recorder: created video files look heavily compressed


after updating the Driveworks version we noticed, that the recorded camera images look very pixelated or heavily compressed using the h264 output format. If the car does not move, the camera frames look quite good but if the car accelerates, more regions of the image get compressed.

Screenshot driving aprox. 70 km/h:

Our recorder configuration:
As we are using the 60° Sekonix camera, the camera-type was set to ar0231-rccb-ss3323, correct? In addition the buffersize was increased, but without any visible impact.

    "version": "0.8",
    "gpu-device": 0,
    "path": "../recordings",
    "log-level": "warn",
    "file-buffer-size": 4194304,
    "camera": {
        "separate-thread": true,
        "record-thread-priority": 0,
        "write-file-pattern": "video_*",
        "sensors": [
                "protocol": "camera.gmsl",
                "params": "camera-type=ar0231-rccb-ss3323,csi-port=ab,camera-count=1,async-record=1,fifo-size=6,output-format=h264",
                "channel-names": [
    "can": {
        "separate-thread": true,
        "write-file-pattern": "can_*",
        "sensors": [
                "protocol": "can.socket",
                "params": "device=can1",
                "channel-name": "0"
    "driveworks-version": {
        "major": 0,
        "minor": 6,
        "patch": 67,
        "hash": "51bd3aae95ffafdf5d76d618fb541f0599cccba8",
        "extra": ""

One thing we noticed: the log.txt points out:

1544542398742292[W]: CameraGMSL: serializer bitrate not specified. Using 8000000.
1544542398818211[D]: Record file(sensor type = 0, channel = 0, path = '/media/nvidia/PXTurbo/recordingJohann/recordings/dw_2018_12_11_15:33:18_000911_monoF60CAN-2xBuff/video_F60.h264): Added to monitoring list

How can the recorder be configured, so that the image quality is not impaired?


Dear JHaselberger,
In DW 1.2, I don’t see ar0231-rccb-ss3323 flag for camera-type parameter in sample_sensor_info. Could you please check with ar0231-rccb-bae-ss3323 or ar0231-rccb-ae-ss3323.

Hello SivaRamaKrishna,

thank you for your reply.
Actually I can’t find any sample_sensor_info application.

If you have a look at the DriveWorks SDK Reference, you’ll find the Sensor Enumeration Sample.
Under camera.gmsl there is ar0231-rccb-ss3323 listed as sensor-type.

What about the serializer bitrate - can this parameter be changed somehow?

Dear JHaselberger,
It seems, you are referring to DW 0.6 documentation. As you mentioned you have updated to latest DW which means DW 1.2, could you please check the same flags in Sensor Enumeration Sample at <DRIVE_Software_PATH>/dav/dwx_sensor_enum_sample.html)

We have DW 1.2 in our latest SDK. If you are using DW 0.6, could you please check this symtom on DW 1.2?

After analyzing the recorded video, we found some glitches in addition.

We’ll try the recorder with an updated driveworks version and report the results.

Dear JHaselberger,
Do you see any issues with latest SDK?

Hi JHaselberger,

Have you managed to verify with the latest SDK?
Any status/result can be shared?


Sorry for the delay, but we had Christmas holidays.

Now we are using the latest dw version 1.2 - but still had some troubles with the recorders:

GUI recorder (recorder-qtgui):
Even if we specify a particular rig.json it always uses the default one located at /usr/local/driveworks/tools/capture/configs/hyperion7_1. Is this the intended behavior?

CLI recorder (recorder-tui)
Only With the cli recorder we were able to use our own rig.json.
But it’s not clear how to specify parameters like route or driver name.
Setting a desired output path is also not user-friendly.

Image quality
With the default recorder parameters the stored h264 video file looks still poor.
After reading the log messages as done with the older version the same bitrate warning was found, so we simply tried to include the desired bitrate 24000000 as additional parameter within the rig configuration. Surprisingly this worked!
It would be nice, if those parameters are documented for the future and not found by try and error.

As of now, no glitches are present.