Smooth DVR playback: native-rate playback (true 720p90 / 1080p60) via the live-video display path#618
Closed
bob9 wants to merge 2 commits into
Closed
Smooth DVR playback: native-rate playback (true 720p90 / 1080p60) via the live-video display path#618bob9 wants to merge 2 commits into
bob9 wants to merge 2 commits into
Conversation
DVR playback on the goggles dropped frames badly for two reasons: - The menu UI drives the panel at 1080p50, so 60fps DVR files lost 10 frames a second in an uneven 6:5 cadence and 90fps race files lost 40. The player now reads the file's frame rate from the demuxer and retimes the UI output to 1080p60 for the duration of playback (same 148.5MHz pixel clock, so OLED/FPGA settings stay valid), restoring 1080p50 on exit. 90fps files fall into an even 3:2 pulldown, the best the panel path can do. - The recorder muxed with a 1/fps stream time base, rounding every capture timestamp to a whole frame slot and baking judder into the file (the reason behind the "fps=59 or DVR is wrong" workaround). Streams are now muxed on the standard 90kHz clock so timestamps stay exact; this also makes recordings play smoother on PCs.
Follow-up to the playback smoothing fix: instead of playing 90fps race DVR at 60Hz with a 3:2 pulldown, the player now retimes the output to 720p90 while the file plays, showing every frame. The menu stays at 1080p for browsing; starting a 90fps file switches the vdpo output to 720p90 reusing the timing, clock phases and OLED mode already proven by the live 720p90 path, and the video surface is sized 1280x720 to fill it. Exiting the player restores the stock menu timing with a full Display_UI_init. 60fps files keep the lighter 1080p60 retime on the same pixel clock. The retime decision moved from ui_player into the media engine, since the video output rect has to be sized before the decoder pipeline is prepared; failure paths restore the menu timing too.
Author
|
closing to do some more testing |
bob9
changed the title
Author
|
Superseded by #619 - same branch, rewritten after hardware bring-up on both goggle generations. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
DVR recordings of 60 and 90 fps flights judder on playback because the menu UI drives the panel at 1080p50 while the recording's frames arrive at 60/90 fps. This PR plays them at their native rate: 90 fps recordings at true 720p90 (every frame shown), 60 fps at 1080p60.
Why v2 looks nothing like v1
The first version of this PR retimed the display on the FPGA's UI input path. Hardware bring-up falsified that approach: on both goggle generations the UI path only ever locks 1080p50 — every recipe tried (bare vdpo retime, clock phases, MFPGA setups, OLED timing sets) produced an unlocked panel. I closed the PR, built an in-firmware display bench, and found the route that works: enter the genuine live-video display mode and let the decoded video ride the vdpo overlay plane — the same path the OSD uses in race mode every day.
What's here
Credit
The live-video-path architecture and the goggles2 verification are @bolagnaise's work; the goggle v1 bring-up, probe validation and playback UX were done on this side. Field-tested on real race footage on both goggle generations.