RTSP streaming with `VideoStreamerGizmo` freezes after first frame

General
1

Hi everyone,

Another post from me :grinning_face_with_smiling_eyes:

I tried the official AI annotated video with RTSP

Issue

When using the dgstreams.VideoStreamerGizmo, only the very first frame is streamed.
After that the stream freezes and no new frames are pushed to the RTSP server.

The only difference from the example Notebook is that I am NOT using:

with degirum_tools.MediaServer():

I already run MediaMTX as a Docker container, with a listener on:
"rtsp://localhost:8554/live" so Iā€™m skipping the embedded MediaServer and pushing frames directly to MediaMTX.

What happens

  • Pipeline starts normally
  • First frame is processed and streamed
  • Streaming then hangs indefinitely
  • Tried enabling allow_drop=True ā†’ no change

Working test

If I forward the same RTSP input through ffmpeg, MediaMTX accepts frames perfectly:

ffmpeg \
  -rtsp_transport tcp \
  -fflags nobuffer -flags low_delay \
  -i "rtsp://..." \
  -c copy -muxdelay 0 -muxpreload 0 \
  -f rtsp -rtsp_transport tcp \
  "rtsp://localhost:8554/live"

So MediaMTX is working and reachable.

Question

Could someone verify whether this is:

  • a misconfiguration on my side, or
  • a possible bug in degirum_tools.VideoStreamerGizmo?

Why would ffmpeg stream correctly while the VideoStreamerGizmo freezes after the first frame?

Any insights or debugging pointers appreciated!

Thanks :folded_hands:

2

@Hobbes1987 ,

Few questions:

  1. Does original/non-modified rtsp_smart_camera.ipynb example works (assuming you stopped your mediamtx server)?
  2. What if you run mediamtx executable in separate terminal window, not in Docker (make sure your cwd contains mediamtx.yml config file), then comment out with degirum_tools.MediaServer(): line in rtsp_smart_camera.ipynb example: does it still work?
3

Also, what FPS is reported by your RTSP camera by OpenCV?

You can check it this way:

python3 -c "import cv2; cap = cv2.VideoCapture('rtsp://user:pwd@x.y.z.w:554/'); print(cap.get(cv2.CAP_PROP_FPS))"

Some RTSP cameras report incorrect FPS (usually 100.0) which may affect pipeline operation

4

I found out that indeed the FPS logged is 100, another camera logs a neat 30 FPS and with that one the exact code as posted works!

So it might - as you said - have something to do with the incorrect FPS.

5

@Hobbes1987 , we just released degirum-tools ver. 0.22.7 with new parameter for VideoSourceGizmo: fps_override. When your camera reports incorrect FPS you may force VideoSourceGizmo to use fps_override value instead of what camera reports. Hope it will fix your problem.

6

Hi @Hobbes1987, was @vladkā€™s solution regarding VideoSourceGizmo: fps_override able to fix your problem?