"frame period too small" warning

[natevw]

Trying to use trainbot on a test recording from a longer-lensed new USB camera, I end up just getting hundreds of errors logged like:

{"level":"warn","framePeriodS":0.000011111,"time":"2024-05-01T03:04:48.367Z","caller":"/src/internal/pkg/stitch/auto.
go:237","message":"frame period too small"}

And no stiched output.

I see this would be logged by https://github.com/jo-m/trainbot/blob/51c8454c113b29d555ba56ffd4e1718787717d8c/internal/pkg/stitch/auto.go#L237 introduced in https://github.com/jo-m/trainbot/commit/fc92da1706f304c547e89a46c56d495fe7a925d8 but unclear why — if the frame period is too small, does that mean the frame frequency (i.e. fps) of my camera is too fast?

QuickTime player on my main laptop reports it as 32.34fps which doesn't seem particularly high.

[natevw]

Too large to upload to GitHub but if it's helpful, the sample file is temporarily hosted at http://exts.ch/files/train_watch_new_2024_04_28_19_01__2024_04_28_19_04.mp4 and I'm using:

#! /bin/sh

# fetch from binaries artifact of CI run: <https://github.com/jo-m/trainbot/actions>

export INPUT=./train_watch_new_2024_04_28_19_01__2024_04_28_19_04.mp4
export RECT_X=603
export RECT_Y=220
export RECT_W=148
export RECT_H=134
export PX_PER_M=23.7  # e.g. 545 px, divided by assuming locomotive ~23 m long?
export MIN_SPEED_KPH=5
export MAX_SPEED_KPH=200
export CAMERA_FORMAT_FOURCC=YUYV

#rm test.jpg && ffmpeg -ss 00:00:37.05 -i "$INPUT" -frames:v 1 test.jpg

rm -rf data && ./trainbot

with the arm64 build of the latest https://github.com/jo-m/trainbot/actions/runs/8837381153 run.

[jo-m]

Hi

I get a 404 at that URL:

[clonejo]

USB webcams often have a dynamic framerate, since they increase exposure time when the picture is too dark. Another reason could be that the timing information trainbot attaches to the captured frames can be off when the CPU load is too high.

Watch out with dumped video files, you will loose the per-frame timing info and the player (and trainbot on a later import) will just assume a fixed framerate. So this issue may not be reproducible from a recording.

edit: ah ok, i had did not noticed you already got that error when importing a recording.

[natevw]

you already got that error when importing a recording

Okay, so if it is about the framerate then yeah what I'd noticed is that 1 / 0.000011111 works out to about ~90k frames per second! So maybe ffmpeg is just feeding it frames as fast as it can accept them instead of in realtime?

But then I don't have this problem on all files, and I would think that would be with the command line arguments to ffmpeg and not based on the exact file. Hoping to have more time again some evening for more troubleshooting but any tips appreciated!

[natevw]

@jo-m

I get a 404 at that URL

oh sorry, something's misconfigured with my server and the HTTPS is going to the wrong site. with just plain http://exts.ch/files/train_watch_new_2024_04_28_19_01__2024_04_28_19_04.mp4 it should work

(and I'll update my original link too just to save time/confusion for now)

[jo-m]

Well, turns out this was simply a bug, and I used the wrong number from ffprobe.

[jo-m]

Also, I had to increase the max allowed length (rather, make it configurable) because your train was too long for my hardcoded default.

Now spits out this JPEG which my OS previewer cannot display because it's too long:

Thumb:

Command used:

./trainbot \
  --log-pretty \
  --log-level info \
  --input ./train_watch_new_2024_04_28_19_01__2024_04_28_19_04.mp4 \
  --rect-x 603 \
  --rect-y 220 \
  --rect-w 148 \
  --rect-h 134 \
  --px-per-m 23.7 \
  --min-speed-kph 5 \
  --max-speed-kph 200 \
  --max-frame-count-per-seq 10000

[natevw]

Thanks for looking into it and great to hear you found a fix already! I'll try retest myself soon.