Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Timestamp conflicting with camera timestamp #88

Closed
mories76 opened this issue Jan 5, 2020 · 5 comments
Closed

Timestamp conflicting with camera timestamp #88

mories76 opened this issue Jan 5, 2020 · 5 comments

Comments

@mories76
Copy link

mories76 commented Jan 5, 2020

Could you please make the new option of printing the timestamp configurable ?
My camera takes care of this, guess what, also in the upper left corner.

@kpine
Copy link

kpine commented Jan 19, 2020

Is it possible to have the show_timestamp setting applied to the camera stream as well? Having only the FPS looks much better.

image

@kpine
Copy link

kpine commented Jan 19, 2020

Or, how about the ability to just disable the stream overlay completely (both timestamp and fps)? I realized I don't need FPS either, since it's available in the debug/stats endpoint now. Personally, I just use the stream to check object detection and so the overlay is mostly in the way.

@blakeblackshear
Copy link
Owner

What are you using the mjpeg stream for? It is intended to be a debug tool and streaming from that endpoint increases load and steals CPU time from processing detected objects.

@kpine
Copy link

kpine commented Jan 20, 2020

I thought I was using it as a debug tool:

  • Verify the region size settings (I need to visually see them)
  • Observe object tracking so I know my settings are working as expected
  • Debug false positives

Are those not good reasons? Granted I don't use it too often, but when I do I don't need the time stamp and FPS for those purposes, and they just obscure the view. The FPS can be obtained from the debug stats and I'm not sure what I'd need the time for. All that is to say that for my use case the original behavior is preferred...

@blakeblackshear
Copy link
Owner

Those are the right reasons. Just wanted to be sure you weren't trying to use that endpoint to record to an NVR continuously.

luoj1 pushed a commit to luoj1/frigate that referenced this issue Apr 29, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants