Feature/1 rtsp client #2
Merged
Conversation
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
* Added simple RTSP client using native opencv videocapture to open the stream * Added RtspClient class which handles the RTSP / RTP / RTCP packets and properly handles the incoming RTP MJPEG stream (repackaging the split packets and adding the jpeg headers) to show each frame via opencv.
…r, rtp packet, rtp jpeg packet, and jpeg frame. now it is much faster :)
* Added c++ versions of python classes from working python example * Updated python example to be refactored into classes * Added example for running the rtsp client on esp32
* Changed jpeg_header to be object instead of unique ptr in jpeg frame * Added getters for width/height of image in jpeg header and jpeg frame * Updated parsing of mjpeg header rtp_jpeg_packet * Added receive timeout in rtsp_client - defaults to 5 seconds for now
* Removed older camera display code and tasks, updated to use new rtsp_client component * removed multicast socket for now for hardcoded server ip / port for testing. * Added rtsp_client to cmakelists for main
* Updated how memory is managed in the jpeg frame to ensure consistency * Added missing huffman tables to header generation (copied from generated jpeg frames on the camera side) * Updated ordering of header generation to match frames generated * Updated how the frame completeness is tracked to make the code simpler to use
* Keep retrying connection if it fails * Print last frame after connection termination
* Update espp submodule to latest * Update main display task to use latest api * Update to enforce size of image queue
12 tasks
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.
Description
rtsp_clientcomponent which includesrtp_packet.hpprtp_jpeg_packet.hppjpeg_header.hppjpeg_frame.hpprtsp_client.hpprtsp_clientwhich doesn't display anything, just shows that the server is receiving data and prints out the last frame as hex arrayMotivation and Context
#1 - RTSP (RTP+RTCP) with MJPEG transport can have less lag and higher effective framerate than transmitting full jpeg over TCP, and less loss with more control for streaming than pure UDP. The use of MJPEG with a JFIF enables the removal of the huffman tables and larger jpeg headers from the transmitted data, allowing simplified header transmission, with only the compressed quantization tables and scan data comprising the bulk of the transmitted images
How has this been tested?
Running on the esp32-s3-box connected via wifi to the m5stack esp32 timer-cam (which is running the code from esp-cpp/camera-streamer#2)
Screenshots (if appropriate, e.g. schematic, board, console logs, lab pictures):
camera_display_rtsp_compressed.mp4
python_rtsp_client_compressed.mp4
Types of changes
Checklist:
Software
.github/workflows/build.ymlfile to add my new test to the automated cloud build github action.