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

Can --dvr-framerate be an optional parameter? #22

Open
zhouruixi opened this issue Oct 15, 2024 · 3 comments
Open

Can --dvr-framerate be an optional parameter? #22

zhouruixi opened this issue Oct 15, 2024 · 3 comments

Comments

@zhouruixi
Copy link

Why --dvr-framerate parameter must required? Can we just get the frame rate from the video stream?The FPS shows in OSD is the FPS I set in IPC.

@luastoned
Copy link
Collaborator

It could be that you fly with 120/60 but want the recording to be 60 or even 30 fps.. but I think it should be a solid default.

@zhouruixi
Copy link
Author

It could be that you fly with 120/60 but want the recording to be 60 or even 30 fps.. but I think it should be a solid default.

--dvr-framerate does not change the frame rate of the video Correctly.

  • If I set the fps to 60 on IPC, and set --dvr-framerate to 30, the original frame rate of the record video is: 60.000 FPS, and the frame rate is: 30.000 FPS. The video plays at half its normal speed( 30/60=1/2).
  • If I set the fps to 30 on IPC, and set --dvr-framerate to 60, the original frame rate of the record video is: 30.000 FPS, and the frame rate is: 60.000 FPS. The video plays at twice its normal speed( 60/30=2).
    The video plays at twice the normal speed

image

I think:

  • If don't use --dvr-framerate parameter: record according to the original video fps.
  • If use this parameter: record according to the parameter setting. We first need to fix the speed problem I mentioned above.

@seriyps
Copy link
Collaborator

seriyps commented Oct 20, 2024

The FPS shows in OSD is the FPS I set in IPC.

This FPS is calculated by literally counting the number of received frames:

osd_vars.current_framerate = frame_counter*(1000/osd_vars.refresh_frequency_ms);

And the way FPS you specify in commandline is used is quite interesting: for each frame it represents a duration of this frame and current DVR assumes that FPS is constant:

auto res = mp4_h26x_write_nal(mp4wr, frame->data(), frame->size(), 90000/video_framerate);

I think what we can do is to rely on Radxa's clock and just measure the time between frames and write it as frame duration to each individual frame? It's not 100% clear if it's ok to have non-fixed duration. Probably ok, otherwise why would we tag each frame with duration =)

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