4.0 release #229
Merged
4.0 release #229
Conversation
This file contains 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
Add global variable and #define in config to set default. Add new parameter in /control handler and preferences.
…m-webserver into framerate_limit
Putting delay after finishing serving the frame causes image to appear in stream with a lag. The reason for this appears to be that browser relies on next frame content boundary in order to determine the end of image. That means that in order for browser to show frame right after receiving it, server needs to send next frame content boundary right after image itself, and delay to limit framerate should be applied after content boundary, not before it. According to https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html sending first frame without content boundary will likely cause its content to be ignored, which seems to be acceptable price for not treating first iteration of the loop as special case.
entering the loop.
|
|
Next up; merge #195 to this |
* Add framerate limit, print delay in debug dump. * Add global variable and #define in config to set default. * Add new parameter in /control handler and preferences. * Add max fps control in full index page for ovh2640. * Add max fps control for ov3660 index page. * Update API documentation. * Use better name for framerate limit variables. * Change UI to show the same values of framerate control as used in command interface. * Apply framerate limiting delay after serving content boundary. Putting delay after finishing serving the frame causes image to appear in stream with a lag. The reason for this appears to be that browser relies on next frame content boundary in order to determine the end of image. That means that in order for browser to show frame right after receiving it, server needs to send next frame content boundary right after image itself, and delay to limit framerate should be applied after content boundary, not before it. According to https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html sending first frame without content boundary will likely cause its content to be ignored, which seems to be acceptable price for not treating first iteration of the loop as special case. * Fix delay before first frame by sending first request boundary before entering the loop. Co-authored-by: 15498th <user@localhost> Co-authored-by: Owen Carter <[email protected]>
|
@rdragonrydr I think I'm done on the branch now, I'll be merging to master later today. Then I will do a release, after a few days 'settle' time. |
|
OTA went badly broken with esp arduino cores 2.0.1 and 2.0.2, the module would simply reboot every time OTA started. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
I'm rapidly going for a 4.0 release, will assemble a few final fixes here:
XCLKset low initially for maximum compatibility with budget boards etc, expose in UI so the user can then find a good setting.